January 31st, 2022

Why does the Windows debugger engine show a bunch of hex digits after one of the DLL names?

Raymond Chen
Raymond Chen

You’re using the Windows debugger engine, say ntsd or windbg, and some DLLs come with hex digits after their names. What’s up with that?

contoso_7ffe7d0e0000!GetWidgetName:
00007ffe`7d0e2f50 488bc4          mov     rax,rsp
00007ffe`7d0e2f53 48895808        mov     qword ptr [rax+8],rbx
00007ffe`7d0e2f57 48896810        mov     qword ptr [rax+10h],rbp
00007ffe`7d0e2f5b 48897018        mov     qword ptr [rax+18h],rsi
00007ffe`7d0e2f5f 48897820        mov     qword ptr [rax+20h],rdi
00007ffe`7d0e2f63 4156            push    r14
00007ffe`7d0e2f65 4883ec20        sub     rsp,20h
00007ffe`7d0e2f69 33db            xor     ebx,ebx

If you look more closely, you’ll see the reason:

0:001> lm
start             end                 module name
00007ff6`a3b30000 00007ff6`a3c70000   contoso     (deferred)
00007ffe`75730000 00007ffe`759cb000   COMCTL32   (deferred)
00007ffe`7d0e0000 00007ffe`7d0fa000   contoso_7ffe7d0e0000   (deferred)
00007ffe`96110000 00007ffe`962b0000   USER32     (deferred)
00007ffe`962b0000 00007ffe`9636d000   KERNEL32   (deferred)
00007ffe`96380000 00007ffe`966d6000   combase    (deferred)
...

There are two modules named contoso loaded into the same program. The first one gets its name the normal way, since it got there first. The second one sees that its name is already taken, so it generates a unique name by appending the module’s base address.

This name conflict can occur because you have two DLLs with the same name but in different directories. Or it could be a conflict between two modules with the same base name but different extensions. (Sometimes, the debugger disambiguates by appending the extension. I’m not quite sure what the algorithm is.)

Bonus chatter: How did I know this? Did I read the debugger source code? Nope, I just figured it out by direct observation. “Why would the debugger have to add a bunch of extra information to the module name? Maybe because the module name isn’t unique.” It’s like asking, “When Bob goes to some classes, people call him ‘Bob S.’ instead of just Bob. But the other students still go by just their first names.” One thing you might guess is, “Maybe there are two students named Bob in those classes.”

Category
Old New Thing
Topics
Other

Author

Raymond Chen

Raymond has been involved in the evolution of Windows for more than 30 years. In 2003, he began a Web site known as The Old New Thing which has grown in popularity far beyond his wildest imagination, a development which still gives him the heebie-jeebies. The Web site spawned a book, coincidentally also titled The Old New Thing (Addison Wesley 2007). He occasionally appears on the Windows Dev Docs Twitter account to tell stories which convey no useful information.

4 comments

Discussion is closed. Login to edit/delete existing comments.

Newest
Newest Popular Oldest
  • Neil Rashbrook

    At least you can load two DLLs with the same name into the same process… back in 16-bit Windows, you couldn’t have two different modules with the same name. This really annoyed me when a font had chosen the module name I wanted…

  • Matthew van Eerde

    Suppose the following three things happen in this order:
    1. contoso_7ffe7d0e0000.dll is loaded
    2. contoso.dll is loaded
    3. A second contoso.dll is loaded at address 7ffe7d0e0000

    What will the third module be named?

    • Raymond ChenMicrosoft employee Author

      I don’t know. Why don’t you experiment and report back.

      • Christian Ullrich

        They get the same name.

        Below, contoso_7ffe7d0e0000.dll was loaded first at 00007ffc`4dd60000, then contoso.dll at 00007ffc`2bcc0000, and finally the second contoso.dll at its fixed /BASE:"0x7ffe7d0e0000".

        <code>

        Read more

Read next