While the RTL Heap performs all heap operation in an interlocked manner by default, it can be requested not to serialize operations by passing the HEAP_NO_SERIALIZE flag to HeapCreate or HeapAlloc. In this case, the caller is in charge to provide proper synchronization.
As it turns out, things change when Application Verifier heap checks are enabled for this process. To check heap operations, Application Verifier intercepts certain operations. Presumably to protect its own internal data structures, at some points, Avrf enters a critical section, as shown in this stack trace:
Continue »
The documentation of the SYMBOL_INFO structure used by dbghelp contains a glitch. As the structure is of variable length, the documentation for SizeOfStruct states:
Size of the structure, in bytes. This member must be set to sizeof(SYMBOL_INFO). Note that the total size of the data is the SizeOfStruct + MaxNameLen - 1. The reason to subtract one is that the first character in the name is accounted for in the size of the structure.
Continue »
Whereas most Verifier error messages are rather descriptive, this one is not really:
VERIFIER STOP 00000200 : pid 0x2B4: Thread cannot own a critical section. 0000104C : Thread ID. 05274FDC : Critical section address. 09D88FE0 : Critical section debug information address. 010135D4 : Critical section initialization stack trace. Why should not this thread be allowed to own a critical section? What is Application Verifier trying to tell us? Luckily, the stack trace gives a hint:
Continue »
There are situations in which it would be convenient to list which apartment the threads of a process belong to. In case of managed debugging, the !threads command provided by SOS gives this info:
PreEmptive GC Alloc Lock ID ThreadOBJ State GC Context Domain Count APT Exception 0 688 00149528 6020 Enabled 00000000:00000000 00159e68 0 STA 1 f70 00165548 b220 Enabled 00000000:00000000 00159e68 0 MTA (Finalizer) In case of unmanaged debugging, however, no such command exists (at least to my knowledge).
Continue »