You're running Windows XP with SP3 natively on some PC, correct?
Do you build on XP as well or on your non-XP machine.
Can you provide the complete call stack?
ntdll.dll!7c90100b()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
> window-d.exe!sf::priv::MutexImpl::lock() Line 52 + 0xc bytes C++
ntdll.dll!_RtlEnterCriticalSection@4() + 0xb bytes
> window-d.exe!sf::priv::MutexImpl::lock() Line 52 + 0xc bytes C++
window-d.exe!sf::Mutex::lock() Line 57 C++
window-d.exe!sf::Lock::Lock(sf::Mutex & mutex) Line 39 C++
window-d.exe!sf::priv::ClockImpl::getCurrentTime() Line 74 C++
window-d.exe!sf::Clock::Clock() Line 42 + 0x17 bytes C++
window-d.exe!`anonymous namespace'::ConnectionCache::ConnectionCache() Line 43 + 0x1f bytes C++
window-d.exe!`vector constructor iterator'(void * __t, unsigned int __s, int __n, void * (void *)* __f) + 0x17 bytes C++
window-d.exe!`anonymous namespace'::`dynamic initializer for 'connectionCache''() Line 49 + 0x16 bytes C++
msvcr100d.dll!__initterm() + 0x1c bytes
window-d.exe!__tmainCRTStartup() Line 473 + 0xf bytes C
window-d.exe!mainCRTStartup() Line 371 C
kernel32.dll!_BaseProcessStart@4() + 0x23 bytes
Does the following short piece of code also crash?
As for your own code, it seems like you're using some static function call or similar (global variable) to store/construct an sf::Clock object. Since the sf::Clock object will get constructed in global scope, but since the mutex inside the sf::Clock is also in a global scope and because initialization order in a global scope is undefined, it just so happens that the sf::Clock gets initialized before the mutex gets initialized, causing a crash.Note that this bug affected the unmodified SFML demos as well, not just my test projects. That said, well done finding the location of the bug. This is the first time I see the "static initialization order fiasco" (https://isocpp.org/wiki/faq/ctors#static-init-order-on-first-use) in a real project.
So you can fix this by not having an sf::Clock constructed in the global scope.
Additionally you could try and see if this change (https://github.com/SFML/SFML/compare/bugfix/xp_mutex_init) fixes the issue for you.
We'd actually be really glad if you could test this, since we rarely develop things on XP. ;)