{"id":97065,"date":"2017-09-22T07:00:00","date_gmt":"2017-09-22T21:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/?p=97065"},"modified":"2019-03-13T01:17:05","modified_gmt":"2019-03-13T08:17:05","slug":"20170922-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20170922-00\/?p=97065","title":{"rendered":"What does it mean when I get an access violation at a very low address when entering a critical section?"},"content":{"rendered":"

Warning<\/b>: This article talks about implementation details which can change at any time. The information provided is for debugging and diagnostic purposes only. <\/p>\n

A customer found that their server program occasionally crashes in the internal function Rtlp­Wait­On­Critical­Section<\/code> trying to dereference the address 0x00000014<\/code>. <\/p>\n

\n7789dde3 ff4014          inc     dword ptr [eax+14h]\n<\/pre>\n
The dereference was due to a null pointer in the EAX<\/code> register. This was particularly difficult to debug because the problem usually didn’t surface until the program had been running continuously for a week or more. <\/p>\n
The customer chased the null pointer backwards and found that it came from the Debug­Info<\/code> field of the RTL_<\/code>CRITICAL_<\/code>SECTION<\/code> structure. <\/p>\n
\ntypedef struct _RTL_CRITICAL_SECTION\n{\n                                             \/\/ value in memory:\n     PRTL_CRITICAL_SECTION_DEBUG DebugInfo;  \/\/ 0x00000000\n     LONG LockCount;                         \/\/ 0xFFFFFFFC\n     LONG RecursionCount;                    \/\/ 0x00000000\n     PVOID OwningThread;                     \/\/ 0x00000000\n     PVOID LockSemaphore;                    \/\/ 0x00005CDC\n     ULONG SpinCount;                        \/\/ 0x00000000\n} RTL_CRITICAL_SECTION, *PRTL_CRITICAL_SECTION;\n<\/pre>\n
The customer confirmed that, yes, the Debug­Info<\/code> of the critical section they were trying to enter was indeed null. <\/p>\n
Although the customer didn’t do it in their application (at least not knowingly), they did try a test application which passed the CRITICAL_<\/code>SECTION_<\/code>NO_<\/code>DEBUG_<\/code>INFO<\/code> flag to the Initialize­Critical­Section­Ex<\/code> function, in the hopes of inducing a null pointer for the Debug­Info<\/code>, but it didn’t work. When initialized in that way, the Debug­Info<\/code> was set to 0xFFFFFFFF<\/code>. <\/p>\n
Is it possible that this is a critical section that was initialized with the traditional Initialize­Critical­Section<\/code> function, but the attempt to allocate the debug info failed, so the kernel left it null? <\/p>\n
No, that’s not why the the Debug­Info<\/code> is null. If a critical section has no debug info (either explicitly requested as such with the CRITICAL_<\/code>SECTION_<\/code>NO_<\/code>DEBUG_<\/code>INFO<\/code> flag, or because the system couldn’t allocate any debug info), then the Debug­Info<\/code> is set to the special value 0xFFFFFFFF<\/code>. The Debug­Info<\/code> for a valid initialized critical section is never null. <\/p>\n
So what does it mean when the Debug­Info<\/code> is null? The most likely reason is that you are using an uninitialized critical section. Either you never initialized it, or you deleted an initialized critical section (which resets it back to the uninitialized state). <\/p>\n
Other evidence that you have an uninitialized critical section is that the critical section is locked, yet has no owner. Furthermore, the spin count is zero, which occurs only on uniprocessor systems. I suspect the server they are running the program on has more than one core. (Heck, my phone<\/i> has more than one core.) <\/p>\n
Bonus reading<\/b>: Displaying a critical section in the debugger<\/a>. <\/p>\n
Related<\/b>: I hope you werent using those undocumented critical section fields<\/a>. <\/p>\n","protected":false},"excerpt":{"rendered":"
It probably means that you’re entering a critical section that is not initialized.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-97065","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
It probably means that you’re entering a critical section that is not initialized.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/97065","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=97065"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/97065\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=97065"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=97065"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=97065"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}