!!PLEASE BE CAREFUL!! 

I've tested this on my own system, and it just crashes the app. But I've also tested it in a VirtualBox on Win7 and it completely froze the system.

This is the smallest test case I could make, you'll have to download it from:
https://github.com/AndrejMitrovic/temporary/tree/master/hashbug

Extract the hashbug folder, build the app with build.bat, and then keep resizing the window for a few seconds. In just a couple of seconds there's a crash with:

---------------------------
hashbug.exe - Application Error
---------------------------
The instruction at "0x00403b39" referenced memory at "0x0000000c". The memory could not be "read".
---------------------------

First of all, it doesn't matter that there's no WinMain function here, WinMain is just a convention and the bug can be recreated with a WinMain function as well.

If you comment out "import std.utf;" the bug disappears, even though std.utf is never used in the module.

If you change the static hash in BugCallback with a globally shared one "__gshared int[int] hash;" outside the function then the bug seems to go away.

If you replace the line "static int[1] arr = [1];" in BugCallback with "static int[1] arr = [0];", then the crash only happens when exiting.

If you comment out "hash[arr[0]] = 0;" in BugCallback, the bug disappears.

If you replace that line with "hash[0] = 0;", then the crash only happens when exiting.

If you comment out the line "foo ~= 1;" in a completely different function "BugFunction" that runs in another thread, the bug disappears. That function keeps expanding an array, but it doesn't cause a stackoverflow or anything.

DDBG shows this:

Unhandled Exception: EXCEPTION_ACCESS_VIOLATION(0xc0000005) at __aaGetX (0x00403b39) thread(2728)

aaGetX looks like a Hash function from Druntime. So my guess is the hash does something that doesn't work quite well with the Windows timer.