you can’t do much in a signal handler<\/a> because you might have interrupted a block of code which was in the middle of updating some data structures, leaving them momentarily inconsistent. But this exception filter is in an even worse state: Not only is there a good chance that the program is in the middle of updating something and left it in an inconsistent state, you are in fact guaranteed<\/i> that the system is in a corrupted state.<\/p>\nWhy is this a guarantee? Because if the system were in a consistent state, you wouldn’t have crashed!<\/p>\n
Programming is about establishing invariants, perturbing them, and then re-establishing them. It is a game of stepping-stone from one island of consistency to another. But the code that does the perturbing and the re-establishing assumes that it’s starting from a consistent state to begin with. For example, a function that removes a node from a doubly-linked list manipulates some backward and forward link pointers (temporarily violating the linked list invariant), and then when it’s finished, the linked list is back to a consistent state. But this code assumes that the linked list is not corrupted to begin with!<\/p>\n
Let’s look again at that call to ExitProcess<\/code>. That’s going to detach all the DLLs, calling each DLL’s DllMain<\/code> with the DLL_PROCESS_DETACH<\/code> notification. But of course, those DllMain<\/code> are going to assume that the data structures are intact and nothing is corrupted. On the other hand, you know for a fact that these prerequisites are not met\u2014the program crashed precisely because something is corrupted. One DLL might walk a linked list\u2014but you might have crashed because that linked list is corrupted. Another DLL might try to delete a critical section\u2014but you might have crashed because the data structure containing the critical section is corrupted.<\/p>\nHeck, the crash might have been inside somebody’s DLL_PROCESS_DETACH<\/code> handler to begin with, for all you know.<\/p>\n“Yeah, but the documentation for TerminateProcess<\/code> says that it does not clean up shared memory.”<\/p>\nWell, it depends on what you mean by clean up<\/i>. The reference count on the shared memory is properly decremented when the handle is automatically closed as part of process cleanup, and the shared memory will be properly freed once there are no more references to it. It is not cleaned up in the sense of “corruption is repaired”\u2014but of course the operating system can’t do that because it doesn’t know what the semantics of your shared memory block are.<\/p>\n
But this is hardly anything to get concerned about because your program doesn’t know how to un-corrupt the data either<\/i>.<\/p>\n
“It also says that DLLs don’t receive their DLL_PROCESS_DETACH<\/code> notification.”<\/p>\nAs we saw before, this is a good thing in the case of a corrupted process, because the code that runs in DLL_PROCESS_DETACH<\/code> assumes that your process has not been corrupted in the first place. There’s no point running it when you know the process is corrupted<\/i>. You’re just making a bad situation worse.<\/p>\n“It also says that I\/O will be in an indeterminate state.”<\/p>\n
Well yeah, but that’s no worse than what you have now, which is that your I\/O is in an indeterminate state. You don’t know what buffers your process hasn’t flushed, but since your process is corrupted, you have no way of finding out anyway.<\/p>\n
“Are you seriously recommending that I use TerminateProcess<\/code> to exit the last chance exception handler?!?”<\/p>\nYour process is unrecoverably corrupted. (This is a fact, because if there were a way to recover from it, you would have done it instead of crashing<\/i>.) What other options are there?<\/p>\n
Quit while you’re behind.<\/p>\n","protected":false},"excerpt":{"rendered":"
When things are bad, don’t be surprised that they don’t work.<\/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-16043","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
When things are bad, don’t be surprised that they don’t work.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/16043","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=16043"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/16043\/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=16043"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=16043"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=16043"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}