Basic dummy question

Ok, I know this must be totally obvious and everyone knows how to do it, but
everyone doesn’t include “me”. :frowning:

How do I track back to a user stack using Windbg when the thread is waiting
on an event? Or any other time for that matter.

Case in point: I have an old legacy MIDI DLL that has been working fine for
ten years, but causes XP SP2 to hang during boot. I have no idea why. I
can see two stacks in different processes (system processes, not under my
control) that have loaded the DLL. I can see they are waiting on
notification events out of ntdll.dll.

Now: how do I find out where they are in *MY* dll so I can fix whatever the
problem is?

Thanks!

Loren

Loren,

Find the thread, first. I use !process to do this and dump all of the
thread stacks looking to find the one that is passing through the code of
interest.

You can then either just be happy with the level of detail that !process can
give you or you can change contexts to the process/thread hung in your MIDI
DLL with one of .process or .thread.

At that point, you should be able to poke around the stack.

See the WINDBG help for .thread. It has an example of pretty much what you
are trying to do.

Keep in mind that the process pages (including the stack) may not be present
in memory at the time you wish to do this. On XP, the /i parameter to
.process can be usefull if the process has a runnable thread. This will
break the debugger in the target process. This will give you a much better
picture of the environment your DLL is running in.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

“Loren Wilton” wrote in message news:xxxxx@ntdev…
> Ok, I know this must be totally obvious and everyone knows how to do it,
> but
> everyone doesn’t include “me”. :frowning:
>
> How do I track back to a user stack using Windbg when the thread is
> waiting
> on an event? Or any other time for that matter.
>
> Case in point: I have an old legacy MIDI DLL that has been working fine
> for
> ten years, but causes XP SP2 to hang during boot. I have no idea why. I
> can see two stacks in different processes (system processes, not under my
> control) that have loaded the DLL. I can see they are waiting on
> notification events out of ntdll.dll.
>
> Now: how do I find out where they are in MY dll so I can fix whatever
> the
> problem is?
>
> Thanks!
>
> Loren
>
>

Have you considered a static disassembly? If it waits for events there are
only a few functions one can use. Perhaps they are not used too often
throughout the DLL such that a static disassembly could be limited to the
minimum necessary?!

BTW: “system process” refers to usermode code I guess? In this case you
could inject your own “trojan” DLL before the other DLL and hook the
function used to wait for the event to find out …

Cheers,

Oliver

PS: No idea how to achieve this in WinDbg. From privileged code one could
perhaps get the thread context and with it the EIP value.

Ok, I know this must be totally obvious and everyone knows how to do it,
but
everyone doesn’t include “me”. :frowning:

How do I track back to a user stack using Windbg when the thread is
waiting
on an event? Or any other time for that matter.

Case in point: I have an old legacy MIDI DLL that has been working fine
for
ten years, but causes XP SP2 to hang during boot. I have no idea why. I
can see two stacks in different processes (system processes, not under my
control) that have loaded the DLL. I can see they are waiting on
notification events out of ntdll.dll.

Now: how do I find out where they are in *MY* dll so I can fix whatever
the
problem is?

Thanks!

May the source be with you, stranger :wink:

ICQ: #281645
URL: http://assarbad.net

I find that Windbg often doesn’t display the user space stacks initially. I
have to switch to the process’ context (.process) and then do a .reload.
Once that is done, subsequent views of the stack will show the user space
calls.

Pat

David R. Cattley wrote:

Loren,

Find the thread, first. I use !process to do this and dump all of the
thread stacks looking to find the one that is passing through the code of
interest.

You can then either just be happy with the level of detail that !process
can give you or you can change contexts to the process/thread hung in your
MIDI DLL with one of .process or .thread.

At that point, you should be able to poke around the stack.

See the WINDBG help for .thread. It has an example of pretty much what
you are trying to do.

Keep in mind that the process pages (including the stack) may not be
present in memory at the time you wish to do this. On XP, the /i parameter
to
.process can be usefull if the process has a runnable thread. This will
break the debugger in the target process. This will give you a much
better picture of the environment your DLL is running in.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

“Loren Wilton” wrote in message
> news:xxxxx@ntdev…
>> Ok, I know this must be totally obvious and everyone knows how to do it,
>> but
>> everyone doesn’t include “me”. :frowning:
>>
>> How do I track back to a user stack using Windbg when the thread is
>> waiting
>> on an event? Or any other time for that matter.
>>
>> Case in point: I have an old legacy MIDI DLL that has been working fine
>> for
>> ten years, but causes XP SP2 to hang during boot. I have no idea why. I
>> can see two stacks in different processes (system processes, not under my
>> control) that have loaded the DLL. I can see they are waiting on
>> notification events out of ntdll.dll.
>>
>> Now: how do I find out where they are in MY dll so I can fix whatever
>> the
>> problem is?
>>
>> Thanks!
>>
>> Loren
>>
>>