How to load symbols for proper unloaded dll module instance

WINDBG
1

I have a crash in the Explorer process. The crash is in our Shell Extension dll which is unloaded. Problem is that there are more unloaded instancies and AFAIK I cannot select proper module instance in .reload command. The command “.reload /unl /f module.dll” loads symbols for different instance than I can see on the stack.

Is there any way how to workaroud it? Is there some WinDBG extension which allows this?

Thanks in advance,
Bronislav Gabrhelik

2

It seems that address parameter is what I need. I have somehow overlooked it.
.reload [Options] [Module [= Address [, Size [, Timestamp] ] ] ]

-bg

3

What does it mean “is in our shell extension dll which is unloaded”? If
it is unloaded, how can you have a crash in it? And when a DLL is
unloaded, there are no instances of it left, so I don’t see how you can
have “more unloaded instances”. They’re gone, by definition. Please
clarify the question.
joe

I have a crash in the Explorer process. The crash is in our Shell
Extension dll which is unloaded. Problem is that there are more unloaded
instancies and AFAIK I cannot select proper module instance in .reload
command. The command “.reload /unl /f module.dll” loads symbols for
different instance than I can see on the stack.

Is there any way how to workaroud it? Is there some WinDBG extension which
allows this?

Thanks in advance,
Bronislav Gabrhelik

WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

4

> If it is unloaded, how can you have a crash in it?
Simply as a result of a bug, which I am trying to investigate. Given DLL is in-process COM server (Shell Extension), so it is unloaded by COM core after DllCanUnload(). We do finalizing in DllCanUnload() when it allows the unload (returns S_OK), but stopping of the thread pool has somehow timed out, because of some unresponsive thread. I found out that thread is stuck in std:list.erase() which is out of context :-).

I don’t see how you can have “more unloaded instances”.
Believe me that WinDbg shows you also unloaded DLL modules. As a result of ASLR when DLL is unloaded and loaded again it has unique module base address. So in my case it was loaded and unloaded several times.

Thanks,
Bronislav Gabrhelik

5

Try ld command:
ld module /f …\module.dll

If it is unloaded, how can you have a crash in it?
Simply as a result of a bug, which I am trying to investigate. Given DLL is
in-process COM server (Shell Extension), so it is unloaded by COM core after
DllCanUnload(). We do finalizing in DllCanUnload() when it allows the unload
(returns S_OK), but stopping of the thread pool has somehow timed out,
because of some unresponsive thread. I found out that thread is stuck in
std:list.erase() which is out of context :-).

I don’t see how you can have “more unloaded instances”.
Believe me that WinDbg shows you also unloaded DLL modules. As a result of
ASLR when DLL is unloaded and loaded again it has unique module base
address. So in my case it was loaded and unloaded several times.

Thanks,
Bronislav Gabrhelik

WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer