{"id":112504,"date":"2026-07-03T07:00:00","date_gmt":"2026-07-03T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=112504"},"modified":"2026-07-03T11:21:42","modified_gmt":"2026-07-03T18:21:42","slug":"20260703-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20260703-00\/?p=112504","title":{"rendered":"How did we conclude that <TT>CcNamespace.dll<\/TT> was the ringleader of a group of DLLs that unloaded prematurely?"},"content":{"rendered":"<p>When I presented <a title=\"The case of the thread executing from an unloaded third-party DLL\" href=\"https:\/\/devblogs.microsoft.com\/oldnewthing\/20260702-00\/?p=112500\"> my study of a crash caused by a thread executing from an unloaded third-party DLL<\/a>, someone asked how I concluded that <tt>CcNamespace.dll<\/tt> was the ringleader of the family of related DLLs.<\/p>\n<p>The list of recently-unloaded DLLs is recorded in a circular history.\u00b9 So when you see a bunch of DLLs listed in a row, they were unloaded one after the other.\u00b2<\/p>\n<pre>00007ff9`6d7c0000 00007ff9`6d80a000   FabrikamContextMenu.dll\r\n00007ff9`115e0000 00007ff9`1172f000   LitWareSync.dll\r\n00007ff9`643d0000 00007ff9`64681000   CcNamespace.dll\r\n00000000`55440000 00000000`5550b000   LibDB_CloudNs_3.dll\r\n00000000`55860000 00000000`55998000   LibNet_CloudNs_3.dll\r\n00000000`557f0000 00000000`5585b000   LibJson_CloudNs_3.dll\r\n00000000`55510000 00000000`557e7000   LibUtils_CloudNs_3.dll\r\n00000000`561a0000 00000000`56238000   MSVCP100.dll\r\n00000000`56240000 00000000`56312000   MSVCR100.dll\r\n00007ff9`85130000 00007ff9`85167000   EhStorShell.dll\r\n00007ff9`3cac0000 00007ff9`3cb61000   wpdshext.dll\r\n00007ff9`78a00000 00007ff9`78a26000   EhStorAPI.dll\r\n00007ff9`686f0000 00007ff9`68754000   PlayToDevice.dll\r\n00007ff9`67110000 00007ff9`6718d000   provsvc.dll\r\n<\/pre>\n<p>From the similar names, it&#8217;s clear that the <tt>Lib\u27e6...\u27e7.<wbr \/>CloudNs.3.dll<\/tt> DLLs are all closely related.<\/p>\n<p>The name <tt>CcNamespace.dll<\/tt> sort of lines up, if you imagine that <tt>Cc<\/tt> stands for &#8220;Contoso Cloud&#8221; and the <tt>Ns<\/tt> in the other DLL names is short for &#8220;Namespace&#8221;.<\/p>\n<p>I&#8217;m not sure whether the unloaded DLLs list is in forward or reverse chronological order, but it turns out that it&#8217;s not important for this analysis: The <tt>CcNamespace.dll<\/tt> was either the first or last to unload, and the fact that its name is slightly different from the others adds weight to the theory that it was the linchpin that held together the entire family of DLLs.<\/p>\n<p>Why does having a slightly different name factor into it?<\/p>\n<p>The other DLLs seem to be coming from a library of helper DLLs that this company uses and reuses. The one with a slightly different name is the front man, who is assembling a team of assistants from the other DLLs. It&#8217;s like when you attend a wedding reception or other fancy event, you can identify the person in charge of the service staff because they are dressed slightly differently from the others. And you can imagine that if there was some need for the staff to gather together and walk single file, the person in charge would probably be at the front or the end of the line.<\/p>\n<p>Spotting the slightly different name at the start or end of the list is not proof, but it&#8217;s very strong evidence. And we were able to verify this theory by installing a copy of Contoso Cloud from the application compatibility library and seeing which DLL was registered as the namespace extension DLL.<\/p>\n<p>\u00b9 The debugger just adds each unloaded DLL to the array, and when it reaches the end of the array, the &#8220;where to put the next DLL&#8221; wraps around back to the top of the array. Unfortunately, there is no indication in the debugger where the &#8220;where to put the next DLL&#8221; pointer is.<\/p>\n<p>\u00b2 Even they are sequential, you don&#8217;t know how much time has elapsed between them.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Contextual clues.<\/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-112504","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"<p>Contextual clues.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/112504","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=112504"}],"version-history":[{"count":1,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/112504\/revisions"}],"predecessor-version":[{"id":112505,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/112504\/revisions\/112505"}],"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=112504"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=112504"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=112504"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}