case WM_DESTROY:\n CheckWindow(TEXT(“WM_DESTROY received”));\n if (m_cRecurse < 1) {\n m_cRecurse++;\n CheckWindow(TEXT(“WM_DESTROY recursing”));\n DestroyWindow(m_hwnd);\n CheckWindow(TEXT(“WM_DESTROY recursion returned”));\n }\n break;<\/FONT>\n …\n}\n<\/PRE>\n\nWe add some debug traces to make it easier to see what is going on.\nRun the program, then close it, and watch what happens.\n<\/P>\n
\nWM_DESTROY received – window still exists\nWM_DESTROY recursing – window still exists\nWM_DESTROY received – window still exists\nWM_NCDESTROY received – window still exists\nWM_NCDESTROY recursing – window still exists\nWM_DESTROY received – window still exists\nWM_NCDESTROY received – window still exists\nWM_NCDESTROY recursion returned – window no longer exists\nAccess violation – code c0000005\neax=00267160 ebx=00000000 ecx=00263f40 edx=7c90eb94 esi=00263f40 edi=00000000\neip=0003008f esp=0006f72c ebp=0006f73c iopl=0 nv up ei ng nz na pe cy\ncs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000283\n0003008f ?? ???\n<\/PRE>\n\nYikes! What happened?\n<\/P>\n
\nWhen you clicked the “X” button, this started the window destruction\nprocess.\nAs is to be expected,\nthe window received a WM_DESTROY<\/CODE> message,\nbut the program responds to this by attempting to destroy the window\nagain<\/STRONG>.\nNotice that IsWindow<\/CODE> reported that the window still\nexists at this point.\nThis is true: The window does still exist,\nalthough it happens to be in the process of being destroyed.\nIn the original scenario, the code that destroyed the window went\nsomething like\n<\/P>\n\nif (IsWindow(hwndToDestroy)) {\n DestroyWindow(hwndToDestroy);\n}\n<\/PRE>\n\nAt any rate, the recursive call to DestroyWindow<\/CODE>\ncaused a new<\/STRONG> window destruction cycle to begin,\nnested inside the first one.\nThis generates a new WM_DESTROY<\/CODE> message,\nfollowed by a WM_NCDESTROY<\/CODE> message.\n(Notice that this window has now received\ntwo<\/STRONG> WM_DESTROY<\/CODE> messages!)\nOur bizarro code then makes yet another\nrecursive call to DestroyWindow<\/CODE>,\nwhich starts a third<\/STRONG> window destruction cycle.\nThe window gets its third WM_DESTROY<\/CODE> message,\nthen its second WM_NCDESTROY<\/CODE> message, at which point\nthe second recursive call to DestroyWindow<\/CODE> returns.\nAt this point, the window no longer exists:\nDestroyWindow<\/CODE> has destroyed the window.\n<\/P>\n\nAnd that’s why we crash.\nThe base Window<\/CODE> class\nhandles the WM_NCDESTROY<\/CODE> message by destroying the\ninstance variables associated with the window.\nTherefore, when the innermost DestroyWindow<\/CODE>\nreturns, the instance variables have been thrown away.\nExecution then resumes with the base class’s\nWM_NCDESTROY<\/CODE> handler, which tries to access\nthe instance variables and gets heap garbage,\nand then makes the even worse no-no of freeing memory that\nis already freed, thereby corrupting the heap.\nIt is here that we crash, attempting to call the virtual\ndestructor on an already-destructed object.\n<\/P>\n\nI intentionally chose to use the new scratch program\n(which uses C++ objects) instead of the classic scratch program\n(which uses global variables) to highlight the fact that\nafter the recursive DestroyWindow<\/CODE> call,\nall the instance variables are gone and you are operating on\nfreed memory.\n<\/P>\n\nMoral of the story:\nUnderstand your window lifetimes\nand don’t destroy a window that you know already to be\nin the process of destruction.<\/p>\n","protected":false},"excerpt":{"rendered":"
Last time, I alluded to weirdness that can result in the normal cycle of destruction messages being thrown out of kilter. Commenter Adrian noted that the WM_GETMINMAXINFO message arrives before WM_NCCREATE for top-level windows. This is indeed unfortunate but (mistake or not) it’s been that way for over a decade and changing it now would […]<\/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-34793","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Last time, I alluded to weirdness that can result in the normal cycle of destruction messages being thrown out of kilter. Commenter Adrian noted that the WM_GETMINMAXINFO message arrives before WM_NCCREATE for top-level windows. This is indeed unfortunate but (mistake or not) it’s been that way for over a decade and changing it now would […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/34793","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=34793"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/34793\/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=34793"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=34793"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=34793"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}