I have here a “complete memory dump” and it looks like the BSOD was caused
by a user mode call into the kernel.
How do I see the current process ?
How do I list the loaded modules for that process ?
A complete kernel memory dump works very much like a live kd session.
You use !process to look at process state, lm to look at modules,
.reload to refresh module lists, etc.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of jim
Sent: Wednesday, January 25, 2006 9:15 AM
To: Kernel Debugging Interest List
Subject: [windbg] Current Process
I have here a “complete memory dump” and it looks like the BSOD was
caused by a user mode call into the kernel.
How do I see the current process ?
How do I list the loaded modules for that process ?
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Call? Do you mean via a ReadFile, WriteFile, or DeviceIoControl?
Gary G. Little
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of jim
Sent: Wednesday, January 25, 2006 11:15 AM
To: Kernel Debugging Interest List
Subject: [windbg] Current Process
I have here a “complete memory dump” and it looks like the BSOD was caused
by a user mode call into the kernel.
How do I see the current process ?
How do I list the loaded modules for that process ?
You are currently subscribed to windbg as: xxxxx@seagate.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Well, yes I know I can use .process, but how do I see what the current
process was at the moment.
“jim” wrote in message news:xxxxx@windbg…
>I have here a “complete memory dump” and it looks like the BSOD was caused
>by a user mode call into the kernel.
> How do I see the current process ?
> How do I list the loaded modules for that process ?
>
>
Well ya.
Here:
nt!KeBugCheckEx+0x1b
nt!MmAccessFault+0x6f5
nt!KiTrap0E+0xcc
nt!CmpGetValueKeyFromCache+0x89
nt!CmpFindValueByNameFromCache+0x65
nt!CmQueryValueKey+0x96
nt!NtQueryValueKey+0x2cc
nt!KiFastCallEntry+0xf8
WARNING: Frame IP not in any known module. Following frames may be wrong.
0x7c90eb94
wrote in message news:xxxxx@windbg…
> Call? Do you mean via a ReadFile, WriteFile, or DeviceIoControl?
>
> Gary G. Little
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of jim
> Sent: Wednesday, January 25, 2006 11:15 AM
> To: Kernel Debugging Interest List
> Subject: [windbg] Current Process
>
> I have here a “complete memory dump” and it looks like the BSOD was caused
>
> by a user mode call into the kernel.
> How do I see the current process ?
> How do I list the loaded modules for that process ?
>
>
>
> —
> You are currently subscribed to windbg as: xxxxx@seagate.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
Unless the kernel API specifically involves a process switch the current
process will be the process that made the call. !process -1 0 will show
you the current process. From the stack you sent before this looks like
a direct registry call, which probably didn’t cause a process switch.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of jim
Sent: Wednesday, January 25, 2006 9:47 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Current Process
Well, yes I know I can use .process, but how do I see what the current
process was at the moment.
“jim” wrote in message news:xxxxx@windbg…
>I have here a “complete memory dump” and it looks like the BSOD was
>caused by a user mode call into the kernel.
> How do I see the current process ?
> How do I list the loaded modules for that process ?
>
>
—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
Great - that exactly what I wanted to know.
Unfortunately, lm is showing kernel modules not user mode process modules.
“Drew Bliss” wrote in message
news:xxxxx@windbg…
Unless the kernel API specifically involves a process switch the current
process will be the process that made the call. !process -1 0 will show
you the current process. From the stack you sent before this looks like
a direct registry call, which probably didn’t cause a process switch.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of jim
Sent: Wednesday, January 25, 2006 9:47 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Current Process
Well, yes I know I can use .process, but how do I see what the current
process was at the moment.
“jim” wrote in message news:xxxxx@windbg…
>I have here a “complete memory dump” and it looks like the BSOD was
>caused by a user mode call into the kernel.
> How do I see the current process ?
> How do I list the loaded modules for that process ?
>
>
—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
Hello Jim,
Is !process without parameters does not work for you?
!process 0 0 shows information for all processes in system.
Perhaps you mixed to commands .process and !process.
Best regards / Mit freundlichen Gruessen
*********************************************************
Oleksiy Shatylo
Senior Software Engineer
Nero AG
Im Stoeckmaedle 18
76307 Karlsbad
Germany
E-mail xxxxx@nero.com
NERO - BECAUSE TECHNOLOGY COUNTS
www.nero.com
*********************************************************
This e-mail may contain confidential and/or
privileged information. If you are not the intended
recipient (or have received this e-mail in error)
please notify the sender immediately and destroy
this e-mail. Any unauthorised copying, disclosure
or distribution of the material in this e-mail is
strictly forbidden.
*********************************************************
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of jim
Sent: Wednesday, January 25, 2006 6:47 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Current ProcessWell, yes I know I can use .process, but how do I see what
the current process was at the moment.“jim” wrote in message news:xxxxx@windbg…
> >I have here a “complete memory dump” and it looks like the BSOD was
> >caused by a user mode call into the kernel.
> > How do I see the current process ?
> > How do I list the loaded modules for that process ?
> >
> >
>
>
>
> —
> You are currently subscribed to windbg as: xxxxx@nero.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
When you do a .reload what does it say in the user-module reload pass?
It’s possible the user state was paged out, in which case you would need
to manually reconstruct the module list with .reload
<image.ext>=,.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of jim
Sent: Wednesday, January 25, 2006 10:39 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Current Process
Great - that exactly what I wanted to know.
Unfortunately, lm is showing kernel modules not user mode process
modules.
“Drew Bliss” wrote in message
news:xxxxx@windbg…
Unless the kernel API specifically involves a process switch the current
process will be the process that made the call. !process -1 0 will show
you the current process. From the stack you sent before this looks like
a direct registry call, which probably didn’t cause a process switch.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of jim
Sent: Wednesday, January 25, 2006 9:47 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Current Process
Well, yes I know I can use .process, but how do I see what the current
process was at the moment.
“jim” wrote in message news:xxxxx@windbg…
>I have here a “complete memory dump” and it looks like the BSOD was
>caused by a user mode call into the kernel.
> How do I see the current process ?
> How do I list the loaded modules for that process ?
>
>
—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com</image.ext>
You can use !peb to get the user mode modules loaded.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of jim
Sent: Wednesday, January 25, 2006 10:39 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Current Process
Great - that exactly what I wanted to know.
Unfortunately, lm is showing kernel modules not user mode process
modules.
Nice I didnt know about !process -1 0 myself been looking for it myself.
Along similar lines, is there a way to know what the last thread of
execution was before a context switch? To be more specific, is there a
timestamp associated with when a thread is switched out that I could look up
to form my own conclusion.
“Drew Bliss” wrote in message
news:xxxxx@windbg…
Unless the kernel API specifically involves a process switch the current
process will be the process that made the call. !process -1 0 will show
you the current process. From the stack you sent before this looks like
a direct registry call, which probably didn’t cause a process switch.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of jim
Sent: Wednesday, January 25, 2006 9:47 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Current Process
Well, yes I know I can use .process, but how do I see what the current
process was at the moment.
“jim” wrote in message news:xxxxx@windbg…
>I have here a “complete memory dump” and it looks like the BSOD was
>caused by a user mode call into the kernel.
> How do I see the current process ?
> How do I list the loaded modules for that process ?
>
>
—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
As there seems to be interest in this topic I’ll say a bit more…
Doing the “.reload” command as Drew suggested, I get:
Loading User Symbols
PEB is paged out (Peb.Ldr = 7ffd500c). Type “.hh dbgerr001” for details
If you do the .hh command as recommended above, you will basically be told
sorry Charlie no dice. You can’t expect the dump to also include the page
file (this one was already 100MB!).
All I can say to my user mode engineers, is that it is most likely a bug
some where in windows OR bad memory/hardware in the pc that caused this . As
far as I know they are NOT using direct Zw calls, so it would be the
responsibility of MFC, kernel32.dll, ntdll.dll or the kernel it self to have
detected a bad parameter.
(If anyone disagrees with the above please speak out)
“Satya Das” wrote in message news:xxxxx@windbg…
You can use !peb to get the user mode modules loaded.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of jim
Sent: Wednesday, January 25, 2006 10:39 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Current Process
Great - that exactly what I wanted to know.
Unfortunately, lm is showing kernel modules not user mode process
modules.
>It’s possible the user state was paged out, in which case you would need
to manually reconstruct the module list with .reload
<image.ext>=,.
I’d like to try this…
How do I determine the base and size of the image ?
kd> !process 8998ba50 0x1f
PROCESS 8998ba50 SessionId: 0 Cid: 0a10 Peb: 7ffd5000 ParentCid: 0974
DirBase: 476a6000 ObjectTable: e34f2bf0 HandleCount: 39.
Image: MiniScan.exe
VadRoot 89822e28 Vads 55 Clone 0 Private 664. Modified 4187. Locked 0.
DeviceMap e1b58098
Token e15e8cc8
ElapsedTime 00:00:17.624
UserTime 00:00:02.890
KernelTime 00:00:07.437
QuotaPoolUsage[PagedPool] 30780
QuotaPoolUsage[NonPagedPool] 2200
Working Set Sizes (now,min,max) (1363, 50, 345) (5452KB, 200KB, 1380KB)
PeakWorkingSetSize 1365
VirtualSize 32 Mb
PeakVirtualSize 39 Mb
PageFaultCount 18421
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 725
THREAD 89a0b930 Cid 0a10.0a14 Teb: 7ffdf000 Win32Thread: e161cc28
RUNNING on processor 0
Not impersonating
DeviceMap e1b58098
Owning Process 8998ba50 Image: MiniScan.exe
Wait Start TickCount 91779 Ticks: 0
Context Switch Count 11557 LargeStack
UserTime 00:00:02.0875
KernelTime 00:00:07.0437
Start Address 0x7c810867
Win32 Start Address 0x0040f5ef
Stack Init b4510000 Current b450f548 Base b4510000 Limit b450b000
Call 0
Priority 10 BasePriority 8 PriorityDecrement 2 DecrementCount 16
ChildEBP RetAddr
b450fafc 80523f44 nt!KeBugCheckEx+0x1b (FPO: [Non-Fpo])
b450fb48 804e1718 nt!MmAccessFault+0x6f5 (FPO: [Non-Fpo])
b450fb48 8056e678 nt!KiTrap0E+0xcc (FPO: [0,0] TrapFrame @ b450fb60)
b450fbe0 8056afcd nt!CmpGetValueKeyFromCache+0x89 (FPO: [Non-Fpo])
b450fc3c 8056b2ae nt!CmpFindValueByNameFromCache+0x65 (FPO:
[Non-Fpo])
b450fc9c 8056b236 nt!CmQueryValueKey+0x96 (FPO: [Non-Fpo])
b450fd44 804de7ec nt!NtQueryValueKey+0x2cc (FPO: [Non-Fpo])
b450fd44 7c90eb94 nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @
b450fd64)
WARNING: Frame IP not in any known module. Following frames may be wrong.
0012cd8c 00000000 0x7c90eb94
“Drew Bliss” wrote in message
news:xxxxx@windbg…
When you do a .reload what does it say in the user-module reload pass?
It’s possible the user state was paged out, in which case you would need
to manually reconstruct the module list with .reload
<image.ext>=,.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of jim
Sent: Wednesday, January 25, 2006 10:39 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Current Process
Great - that exactly what I wanted to know.
Unfortunately, lm is showing kernel modules not user mode process
modules.
“Drew Bliss” wrote in message
news:xxxxx@windbg…
Unless the kernel API specifically involves a process switch the current
process will be the process that made the call. !process -1 0 will show
you the current process. From the stack you sent before this looks like
a direct registry call, which probably didn’t cause a process switch.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of jim
Sent: Wednesday, January 25, 2006 9:47 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Current Process
Well, yes I know I can use .process, but how do I see what the current
process was at the moment.
“jim” wrote in message news:xxxxx@windbg…
>I have here a “complete memory dump” and it looks like the BSOD was
>caused by a user mode call into the kernel.
> How do I see the current process ?
> How do I list the loaded modules for that process ?
>
>
—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com</image.ext></image.ext>
If you know the executable you can get the size from the PE image
header. You can also get the preferred load address from the PE image
header, which is usually the address it loads at (although conflicts can
prevent that).
If you have time for a brute-force approach you can have the debugger do
an automatic scan with .imgscan.
.imgscan -l -r 10000 l?7fff0000
-l means add a module list entry when an image is found, -r gives the
range to scan (low 32-bits in this case). Note that this search will be
foiled by missing user-mode pages, which is relatively common as PE
image headers aren’t touched and get paged out easily.
For OS images, which usually load at the same addresses all of the time,
you can simply start another process on the same machine under a
user-mode debugger and look at the system modules. This will give you
the location and size for ntdll, kernel32 and other OS modules that are
usually right after a kernel transition.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of jim
Sent: Thursday, January 26, 2006 7:26 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Current Process
It’s possible the user state was paged out, in which case you would
need to manually reconstruct the module list with .reload
<image.ext>=,.
I’d like to try this…
How do I determine the base and size of the image ?
kd> !process 8998ba50 0x1f
PROCESS 8998ba50 SessionId: 0 Cid: 0a10 Peb: 7ffd5000 ParentCid:
0974
DirBase: 476a6000 ObjectTable: e34f2bf0 HandleCount: 39.
Image: MiniScan.exe
VadRoot 89822e28 Vads 55 Clone 0 Private 664. Modified 4187. Locked
0.
DeviceMap e1b58098
Token e15e8cc8
ElapsedTime 00:00:17.624
UserTime 00:00:02.890
KernelTime 00:00:07.437
QuotaPoolUsage[PagedPool] 30780
QuotaPoolUsage[NonPagedPool] 2200
Working Set Sizes (now,min,max) (1363, 50, 345) (5452KB, 200KB,
1380KB)
PeakWorkingSetSize 1365
VirtualSize 32 Mb
PeakVirtualSize 39 Mb
PageFaultCount 18421
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 725
THREAD 89a0b930 Cid 0a10.0a14 Teb: 7ffdf000 Win32Thread:
e161cc28 RUNNING on processor 0
Not impersonating
DeviceMap e1b58098
Owning Process 8998ba50 Image:
MiniScan.exe
Wait Start TickCount 91779 Ticks: 0
Context Switch Count 11557 LargeStack
UserTime 00:00:02.0875
KernelTime 00:00:07.0437
Start Address 0x7c810867
Win32 Start Address 0x0040f5ef
Stack Init b4510000 Current b450f548 Base b4510000 Limit
b450b000 Call 0
Priority 10 BasePriority 8 PriorityDecrement 2 DecrementCount 16
ChildEBP RetAddr
b450fafc 80523f44 nt!KeBugCheckEx+0x1b (FPO: [Non-Fpo])
b450fb48 804e1718 nt!MmAccessFault+0x6f5 (FPO: [Non-Fpo])
b450fb48 8056e678 nt!KiTrap0E+0xcc (FPO: [0,0] TrapFrame @
b450fb60)
b450fbe0 8056afcd nt!CmpGetValueKeyFromCache+0x89 (FPO:
[Non-Fpo])
b450fc3c 8056b2ae nt!CmpFindValueByNameFromCache+0x65 (FPO:
[Non-Fpo])
b450fc9c 8056b236 nt!CmQueryValueKey+0x96 (FPO: [Non-Fpo])
b450fd44 804de7ec nt!NtQueryValueKey+0x2cc (FPO: [Non-Fpo])
b450fd44 7c90eb94 nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame
@
b450fd64)
WARNING: Frame IP not in any known module. Following frames may be
wrong.
0012cd8c 00000000 0x7c90eb94
“Drew Bliss” wrote in message
news:xxxxx@windbg…
When you do a .reload what does it say in the user-module reload pass?
It’s possible the user state was paged out, in which case you would need
to manually reconstruct the module list with .reload
<image.ext>=,.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of jim
Sent: Wednesday, January 25, 2006 10:39 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Current Process
Great - that exactly what I wanted to know.
Unfortunately, lm is showing kernel modules not user mode process
modules.
“Drew Bliss” wrote in message
news:xxxxx@windbg…
Unless the kernel API specifically involves a process switch the current
process will be the process that made the call. !process -1 0 will show
you the current process. From the stack you sent before this looks like
a direct registry call, which probably didn’t cause a process switch.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of jim
Sent: Wednesday, January 25, 2006 9:47 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Current Process
Well, yes I know I can use .process, but how do I see what the current
process was at the moment.
“jim” wrote in message news:xxxxx@windbg…
>I have here a “complete memory dump” and it looks like the BSOD was
>caused by a user mode call into the kernel.
> How do I see the current process ?
> How do I list the loaded modules for that process ?
>
>
—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com</image.ext></image.ext>
What I heard from the kernel team is that there isn’t an easy way to
determine the previously running thread. The system doesn’t track the
thread switched away from, and context switches aren’t timestamped in a
default system.
If you use ETW to get kernel trace info you get some context switch
stuff.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of bank kus
Sent: Wednesday, January 25, 2006 9:43 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Current Process
Nice I didnt know about !process -1 0 myself been looking for it myself.
Along similar lines, is there a way to know what the last thread of
execution was before a context switch? To be more specific, is there a
timestamp associated with when a thread is switched out that I could
look up to form my own conclusion.
“Drew Bliss” wrote in message
news:xxxxx@windbg…
Unless the kernel API specifically involves a process switch the current
process will be the process that made the call. !process -1 0 will show
you the current process. From the stack you sent before this looks like
a direct registry call, which probably didn’t cause a process switch.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of jim
Sent: Wednesday, January 25, 2006 9:47 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Current Process
Well, yes I know I can use .process, but how do I see what the current
process was at the moment.
“jim” wrote in message news:xxxxx@windbg…
>I have here a “complete memory dump” and it looks like the BSOD was
>caused by a user mode call into the kernel.
> How do I see the current process ?
> How do I list the loaded modules for that process ?
>
>
—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
Hello, jim
Surely it’s not a usermode bug. Kernel validates all params on syscall
entry,
so is a hardware or kernel bug.
Regards, Dmitry.
“jim” wrote in message news:xxxxx@windbg…
> As there seems to be interest in this topic I’ll say a bit more…
> Doing the “.reload” command as Drew suggested, I get:
>
>>Loading User Symbols
>>PEB is paged out (Peb.Ldr = 7ffd500c). Type “.hh dbgerr001” for details
>
> If you do the .hh command as recommended above, you will basically be told
> sorry Charlie no dice. You can’t expect the dump to also include the page
> file (this one was already 100MB!).
>
> All I can say to my user mode engineers, is that it is most likely a bug
> some where in windows OR bad memory/hardware in the pc that caused this .
> As far as I know they are NOT using direct Zw calls, so it would be the
> responsibility of MFC, kernel32.dll, ntdll.dll or the kernel it self to
> have detected a bad parameter.
>
> (If anyone disagrees with the above please speak out)
>
>
>
> “Satya Das” wrote in message news:xxxxx@windbg…
> You can use !peb to get the user mode modules loaded.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of jim
> Sent: Wednesday, January 25, 2006 10:39 AM
> To: Kernel Debugging Interest List
> Subject: Re:[windbg] Current Process
>
> Great - that exactly what I wanted to know.
> Unfortunately, lm is showing kernel modules not user mode process
> modules.
>
>
>
>
>
>
>