..Just like it says in the topic. The verifier stop is triggered only when Low Resource Simulation is enabled, and it's got me totally stumped. I'm assuming DSound code can handle low resources, but this doesn't make it look like that's the case. Here's a snippet of my output window: First-chance exception at 0x733df4d0 (dsound.dll) in <app>.exe: 0xC0000005: Access violation writing location 0x0000000c. =========================================================== VERIFIER STOP 0000000000000013: pid 0x13D4: first chance access violation for current stack trace 000000000000000C : Invalid address being accessed 00000000733DF4D0 : Code performing invalid access 00000000000DE9A0 : Exception record. Use .exr to display it. 00000000000DE4B0 : Context record. Use .cxr to display it. =========================================================== This verifier stop is continuable. After debugging it use `go' to continue. =========================================================== ======================================= VERIFIER STOP 00000013: pid 0x13D4: First chance access violation for current stack trace. 0000000C : Invalid address causing the exception. 733DF4D0 : Code address executing the invalid access. 0021E9A4 : Exception record. 0021E9F4 : Context record. ======================================= This verifier stop is continuable. After debugging it use `go' to continue. ======================================= <app>.exe has triggered a breakpoint And my call stack:

It's your standard null pointer bug alright. An object is checked for NULL-ness before being accessed but unfortunately in the fail case another NULL pointer is used in it's place. The resultant pointer is pushed into a function, not checked for NULL and bang it goes trying to assign 0 to offset 0xC.

Yeah, I understand what's happening (from the exception info). The question is whose fault is it? It doesn't seem to be mine, and it's annoying that I can't pass AppVerifier because someone doing DS8 didn't check for an allocation returning NULL - which is a noobie mistake so I doubt/wish that's not the case, but I need a second opinion..

Sorry, yes it is DSound.dll that's at fault. I'm kinda surprised as well, since the NULL assignment in the failure case is a quite clear "xor eax, eax" so it's not an accidental or unseen consequence. The method that causes the object to be NULL in the first place does return E_OUTOFMEMORY but it's never checked at the call site.

I looked at the checked version from the Win7 RC and there's no assert in there, so it would seem that NULL was at some point a valid value but the check has either been removed or just never implemented.

Ah, just as I expected. Sucks for me and AppVerifier :(