{"id":97256,"date":"2017-10-20T07:00:00","date_gmt":"2017-10-20T21:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/?p=97256"},"modified":"2019-03-13T01:19:12","modified_gmt":"2019-03-13T08:19:12","slug":"20171020-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20171020-00\/?p=97256","title":{"rendered":"On the gradual improvements in how the system deals with the failure to initialize a critical section"},"content":{"rendered":"

The documentation for the Initialize­Critical­Section<\/code> function<\/a> says <\/p>\n

\n

Return value <\/p>\n

This function does not return a value. <\/p>\n

Windows Server 2003 and Windows XP<\/b>: In low memory situations, Initialize­Critical­Section<\/b> can raise a STATUS_<\/code>NO_<\/code>MEMORY<\/code> exception. This exception was eliminated starting with Windows Vista. <\/p>\n<\/blockquote>\n

In earlier versions of Windows, the Initialize­Critical­Section<\/code> function could fail in low memory conditions, in which case it raised a STATUS_<\/code>NO_<\/code>MEMORY<\/code> exception. <\/p>\n

Wait, let’s go back even further. <\/p>\n

In very old versions of Windows, the Initialize­Critical­Section<\/code> function could fail in low memory conditions, in which case it raised a STATUS_<\/code>NO_<\/code>MEMORY<\/code> exception. However, the code wasn’t particularly careful about exactly when it raised the exception, and it turns out that it didn’t bother to completely unwind the partial-initialization-so-far before raising the exception. This means that if a program tried to recover from a failed Initialize­Critical­Section<\/code> by catching the STATUS_<\/code>NO_<\/code>MEMORY<\/code> exception, it still experienced a memory leak. <\/p>\n

Yes, it’s rather ironic that if the kernel couldn’t initialize the critical section due to low resources, it leaked memory, which made the low resource situation even worse<\/i>. <\/p>\n

There was a similar sad story with Enter­Critical­Section<\/code> and even Leave­Critical­Section<\/code>: Under low resource conditions, those functions could fail and raise a STATUS_<\/code>NO_<\/code>MEMORY<\/code> exception. Those are even worse because by the time you get the exception, it’s probably too late to back out of whatever you were doing. I mean, maybe if you’re really clever, you can recover from a failed Enter­Critical­Section<\/code> by abandoning the operation (and undoing all the work done so far), but I can’t think of any case where a program could do anything reasonable if Leave­Critical­Section<\/code> fails. <\/p>\n

And as Michael Grier noted<\/a>, if Leave­Critical­Section<\/code> raised an exception, not only wasn’t there anything you could reasonably do about it, but it also left the critical section in a corrupted state! <\/p>\n

The only thing you can do is to just crash the process before things get any worse. <\/p>\n

I think it was in Windows XP that the kernel folks fixed the code so that it cleaned up the partially-initialized critical section before raising the STATUS_<\/code>NO_<\/code>MEMORY<\/code> exception, so that a program could safely catch the exception and not leak memory. I believe they also fixed it so that the Enter­Critical­Section<\/code> and Leave­Critical­Section<\/code> functions would not raise exceptions. If called properly, then they always succeeded. So at least those weird cases of “raising an exception and leaving the critical section fatally corrupted” went away. <\/p>\n

And then in Windows Vista, the kernel folks decided to get rid of the problem once and for all and remove all the failure cases from all the critical section functions. The Initialize­Critical­Section<\/code> and Initialize­Critical­Section­And­Spin­Count<\/code> functions always succeeded. The Enter­Critical­Section<\/code> and Leave­Critical­Section<\/code> functions would not raise exceptions when used properly. <\/p>\n

So for over a decade now, the Initialize­Critical­Section<\/code> and Initialize­Critical­Section­And­Spin­Count<\/code> functions never fail. This means that (assuming they are called properly), Initialize­Critical­Section<\/code> never raises a STATUS_<\/code>NO_<\/code>MEMORY<\/code> exception. The Initialize­Critical­Section­And­Spin­Count<\/code> function a return value that says whether it succeeded, but it always succeeds and returns a nonzero value. The return value is now superfluous. <\/p>\n

Bonus chatter<\/b>: The documentation for the Initialize­Critical­Section­And­Spin­Count<\/code> function<\/a> says <\/p>\n

\n

Return value <\/p>\n

This function always returns a nonzero value. <\/p>\n

Windows Server 2003 and Windows XP<\/b>: If the function succeeds, the return value is nonzero. If the function fails, the return value is zero (0). To get extended error information, call Get­Last­Error<\/b>. This behavior was changed starting with Windows Vista. <\/p>\n<\/blockquote>\n

I’m told that some people come away from the documentation still worried about the possibility that the Initialize­Critical­Section­And­Spin­Count<\/code> might fail on Windows Vista and later. They see that on Windows Server 2003 and Windows XP, the function tells you whether or not it succeeded, but on Windows Vista it always reports success. “That means that if the function fails, Windows Vista will lie to me and report success even though it failed!” No, that’s not what it’s saying. It’s saying that starting in Windows Vista, the function never fails<\/i>. <\/p>\n","protected":false},"excerpt":{"rendered":"

Gradually improve the situation until the problem vanishes completely.<\/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-97256","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"

Gradually improve the situation until the problem vanishes completely.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/97256","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=97256"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/97256\/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=97256"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=97256"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=97256"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}