¶You forgot to mention a small detail
Hmm, looks like someone says my program crashed, and sent me the minidump. Excellent! Let's load it in WinDbg, my favorite tool for post-mortem debugging (since it offers more control than Visual Studio):
(8.9): Unknown exception - code 80000101 (first/second chance not available)
eax=00000000 ebx=00004120 ecx=00004120 edx=00000006 esi=f75d5079 edi=f75f4ff4
eip=f779d430 esp=0033e818 ebp=0033e830 iopl=0 nv up ei ng nz ac pe nc
cs=0023 ss=002b ds=002b es=002b fs=0063 gs=006b efl=00200296
I don't recognize that exception code. The PC value is a bit weird, too -- that's in kernel address space for 32-bit Windows, even with /3GB. Well, let's set up symbols and dump the stack.
0:003> .sympath e:alt17
Symbol search path is: e:alt17
0:003> .symfix+ f:symbols
0:003> .reload
.................................
0:003> k
*** WARNING: Unable to verify timestamp for ntdll.dll
*** ERROR: Module load completed but symbols could not be loaded for ntdll.dll
That's weird, the symbols for this system's ntdll.dll aren't on the Microsoft public symbol server? What's loaded on this system?
0:003> lm
start end module name
00400000 00b0b000 Altirra (private pdb symbols) e:alt17Altirra.pdb
7c860000 7c869000 psapi (deferred)
7c870000 7c8c3000 dbghelp (deferred)
7cdd0000 7cf02000 wined3d T (no symbols)
7cf50000 7cf7f000 d3d9 T (no symbols)
7cf90000 7cfb9000 dinput (deferred)
7cfd0000 7d0a4000 oleaut32 (deferred)
7d0b0000 7d100000 riched20 (deferred)
7d230000 7d24a000 dinput8 (deferred)
7d250000 7d25e000 riched32 (deferred)
7d260000 7d274000 midimap (deferred)
7d280000 7d29c000 msacm32_7d280000 (deferred)
7dda0000 7ddb1000 msacm32 (deferred)
7ddc0000 7ddcf000 winepulse (deferred)
7ddd0000 7ddea000 spoolss (deferred)
7df50000 7df61000 localspl (deferred)
7dfa0000 7dfcf000 uxtheme (deferred)
7e000000 7e019000 imm32 (deferred)
7e190000 7e227000 winex11 (deferred)
7e2f0000 7e381000 winmm (deferred)
7e390000 7e3f8000 rpcrt4 (deferred)
7e410000 7e4fa000 ole32 (deferred)
7e500000 7e533000 winspool (deferred)
7e540000 7e622000 comctl32 (deferred)
7e630000 7e687000 shlwapi (deferred)
7e6a0000 7e875000 shell32 (deferred)
7e880000 7e937000 comdlg32 (deferred)
7e940000 7e995000 advapi32 (deferred)
7e9a0000 7ea22000 gdi32 (deferred)
7ea40000 7eb58000 user32 (deferred)
7ed70000 7eedb000 KERNEL32 (deferred)
7ef30000 7ef43000 version (deferred)
7ef60000 7f000000 ntdll T (no symbols)
Ummm... okaaay. It looks like the user forgot to tell me a small detail, namely that he wasn't actually running my Windows-based program under Windows... but actually under Linux using WINE. Which means there are a whole new class of issues that could be involved, the least of which being that WINE's D3D9 implementation has some known issues related to D3D<->OpenGL translation.
Fortunately for this particular user, it turns out that in this case the issue is actually likely to be on my end and related to a known problem in VirtualDub's D3D9 rendering code that I already fixed. However, if you're going to run a program under an environment that it was definitely not intended to run under and which may have its own problems (or is likely to have problems!), you need to mention your non-standard configuration to whoever's looking at your problem.