{"id":45004,"date":"2015-05-29T07:00:00","date_gmt":"2015-05-29T21:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2015\/05\/29\/under-what-conditions-can-setfocus-crash-another-debugging-investigation\/"},"modified":"2019-03-13T12:15:52","modified_gmt":"2019-03-13T19:15:52","slug":"20150529-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20150529-00\/?p=45004","title":{"rendered":"Under what conditions can SetFocus crash? Another debugging investigation"},"content":{"rendered":"<p>A customer asked, &#8220;Under what conditions can <code>Set&shy;Focus<\/code> crash?&#8221; <\/p>\n<blockquote CLASS=\"q\">\n<p>We have been <a HREF=\"http:\/\/msdn.microsoft.com\/en-us\/library\/windows\/hardware\/dn641144.aspx\">going through our error reports<\/a> and are puzzled by this one. The call stack is as follows: <\/p>\n<pre>\nuser32!_except_handler4\nntdll!ExecuteHandler2@20\nntdll!ExecuteHandler@20\nntdll!RtlDispatchException\nntdll!_KiUserExceptionDispatcher@8\n0x130862\nuser32!UserCallWinProcCheckWow\nuser32!__fnDWORD\nntdll!_KiUserCallbackDispatcher@12\nuser32!NtUserSetFocus\ncontoso!DismissPopup\n<\/pre>\n<p>At the point of the crash, the <code>Dismiss&shy;Popup<\/code> function is calling <code>Set&shy;Focus<\/code> to restore focus to a window handle that we got from an earlier call to <code>Get&shy;Active&shy;Window<\/code>. Is this safe? We imagine it might crash if the message handler for the window was unloaded from memory without being properly unregistered; are there any other reasons? More to the point, is there any way to avoid the problem (without fixing the root cause of the crash, which we may not be able to do, e.g. if that window was created by third-party code)? <\/p>\n<p>The full dump file can be found on &lt;location&gt;. The password is &lt;xyzzy&gt;. <\/p>\n<\/blockquote>\n<p>Indeed, what the customer suspected is what happened, confirmed by the dump file provided. <\/p>\n<p>The code behind the window procedure got unloaded. <code>User&shy;Call&shy;Win&shy;Proc&shy;Check&shy;Wow<\/cODE> is trying to call the window procedure, but instead it took an exception. The address doesn't match any loaded or recently-unloaded module probably because it was a dynamically generated thunk, <a HREF=\"http:\/\/blogs.msdn.com\/b\/oldnewthing\/archive\/2007\/11\/16\/6281925.aspx\">like the ones ATL generates<\/a>. <\/p>\n<p>There isn't much you can do to defend against this. Even if you manage to detect the problem and avoid calling <code>Set&shy;Focus<\/code> in this problematic case, all you're doing is kicking the can further down the road. Your program will crash the next time the window receives a message, which it eventually will. (For example, the next time the user changes a system setting and the <code>WM_SETTING&shy;CHANGE<\/code> message is broadcast to all top-level windows, or the user plugs in an external monitor and the <code>WM_DISPLAY&shy;CHANGE<\/code> message is broadcast to all top-level windows.) <\/p>\n<p>Basically, that other component pulled the pin on a grenade and handed it to your thread. That grenade is going to explode sooner or later. The only question is when. <\/p>\n<p>Such is the danger of giving your application an extension model that allows arbitrary third party code to run. The third party code can do good things to make your program more useful, but it can also do bad things to make your program crash. <\/p>\n","protected":false},"excerpt":{"rendered":"<p>SetFocus is the symptom, not the cause.<\/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":[26],"class_list":["post-45004","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-other"],"acf":[],"blog_post_summary":"<p>SetFocus is the symptom, not the cause.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/45004","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=45004"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/45004\/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=45004"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=45004"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=45004"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}