How to Find UID of running process that caused panic ? Is it possible ? [SEC=UNCLASSIFIED]

WINDBG
1

Hi all,

I have a core dump that appears to have been caused by a process
called radixgui.exe. Question: Is it possible to find out the UID that
this process was running as when the panic occured (using windbg) ?

Here is the backtrace (trimmed):

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx”
referenced memory at “0x%08lx”. The memory could not be “%s”.

…

DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x8E
PROCESS_NAME: radixgui.exe
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from e105bba7 to e107c4a0

STACK_TEXT:
f21157ac e105bba7 0000008e c0000005 fc72b929 nt!KeBugCheckEx+0x1b
f2115b70 e10346cc f2115b8c 00000000 f2115be0 nt!KiDispatchException +0x3a2
f2115bd8 e1034680 f2116c3c fc72b929 badb0d00 nt!CommonDispatchException +0x4a
f2115c60 dd8ad3cd 00000000 e7520c60 e720b0d0 nt!Kei386EoiHelper+0x186
f2116c3c e1040153 faaaea40 faf4e578 fa9311d0 win32k!EXLATEOBJ::bInitXlateObj+0xbb
f2116c50 e112b57f faf4e5e8 fa9311d0 faf4e578 nt!IofCallDriver+0x45
f2116c64 e112b4b4 faaaea40 faf4e578 fa9311d0 nt!IopSynchronousServiceTail+0x10b
f2116d00 e112b5d4 0000012c 00000000 00000000 nt!IopXxxControlFile+0x60f
f2116d34 e1033bef 0000012c 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
f2116d34 7c82860c 0000012c 00000000 00000000 nt!KiFastCallEntry+0xfc

Thanks

-Alex

IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email.

2

Not sure if there is a easier way but what I do somethings if its a full
memory dump you could switch into the process

.process /p /r

and then look at the environment block

!peb

Normally the username can be obtained from inside an environment variable.

Tom
On Mon, Feb 14, 2011 at 2:18 PM, Wilkinson, Alex <
xxxxx@dsto.defence.gov.au> wrote:

> Hi all,
>
> I have a core dump that appears to have been caused by a process
> called radixgui.exe. Question: Is it possible to find out the UID that
> this process was running as when the panic occured (using windbg) ?
>
>
> Here is the backtrace (trimmed):
>
>
> EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx”
> referenced memory at “0x%08lx”. The memory could not be “%s”.
>
> …
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
> BUGCHECK_STR: 0x8E
> PROCESS_NAME: radixgui.exe
> CURRENT_IRQL: 0
> LAST_CONTROL_TRANSFER: from e105bba7 to e107c4a0
>
> STACK_TEXT:
> f21157ac e105bba7 0000008e c0000005 fc72b929 nt!KeBugCheckEx+0x1b
> f2115b70 e10346cc f2115b8c 00000000 f2115be0 nt!KiDispatchException
> +0x3a2
> f2115bd8 e1034680 f2116c3c fc72b929 badb0d00 nt!CommonDispatchException
> +0x4a
> f2115c60 dd8ad3cd 00000000 e7520c60 e720b0d0 nt!Kei386EoiHelper+0x186
> f2116c3c e1040153 faaaea40 faf4e578 fa9311d0
> win32k!EXLATEOBJ::bInitXlateObj+0xbb
> f2116c50 e112b57f faf4e5e8 fa9311d0 faf4e578 nt!IofCallDriver+0x45
> f2116c64 e112b4b4 faaaea40 faf4e578 fa9311d0
> nt!IopSynchronousServiceTail+0x10b
> f2116d00 e112b5d4 0000012c 00000000 00000000 nt!IopXxxControlFile+0x60f
> f2116d34 e1033bef 0000012c 00000000 00000000
> nt!NtDeviceIoControlFile+0x2a
> f2116d34 7c82860c 0000012c 00000000 00000000 nt!KiFastCallEntry+0xfc
>
>
> Thanks
>
>
> -Alex
>
>
>
>
> IMPORTANT: This email remains the property of the Department of Defence and
> is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you
> have received this email in error, you are requested to contact the sender
> and delete the email.
>
> —
> 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
>

3

You could look at the token for the process assuming that you have full kernel memory available. This will probably not work if the dump is just a minidump.

!process 1 (@$proc represents the current process)
Then, !token on the token pointer displayed to get the SID.

- S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Wilkinson, Alex
Sent: Monday, February 14, 2011 6:19 AM
To: Kernel Debugging Interest List
Subject: [windbg] How to Find UID of running process that caused panic ? Is it possible ? [SEC=UNCLASSIFIED]

Hi all,

I have a core dump that appears to have been caused by a process called radixgui.exe. Question: Is it possible to find out the UID that this process was running as when the panic occured (using windbg) ?

Here is the backtrace (trimmed):

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx”
referenced memory at “0x%08lx”. The memory could not be “%s”.

…

DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x8E
PROCESS_NAME: radixgui.exe
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from e105bba7 to e107c4a0

STACK_TEXT:
f21157ac e105bba7 0000008e c0000005 fc72b929 nt!KeBugCheckEx+0x1b
f2115b70 e10346cc f2115b8c 00000000 f2115be0 nt!KiDispatchException +0x3a2
f2115bd8 e1034680 f2116c3c fc72b929 badb0d00 nt!CommonDispatchException +0x4a
f2115c60 dd8ad3cd 00000000 e7520c60 e720b0d0 nt!Kei386EoiHelper+0x186
f2116c3c e1040153 faaaea40 faf4e578 fa9311d0 win32k!EXLATEOBJ::bInitXlateObj+0xbb
f2116c50 e112b57f faf4e5e8 fa9311d0 faf4e578 nt!IofCallDriver+0x45
f2116c64 e112b4b4 faaaea40 faf4e578 fa9311d0 nt!IopSynchronousServiceTail+0x10b
f2116d00 e112b5d4 0000012c 00000000 00000000 nt!IopXxxControlFile+0x60f
f2116d34 e1033bef 0000012c 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
f2116d34 7c82860c 0000012c 00000000 00000000 nt!KiFastCallEntry+0xfc

Thanks

-Alex

IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email.

—
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

0n Mon, Feb 14, 2011 at 09:27:34AM -0600, Skywing wrote:

You could look at the token for the process assuming that you have full
>kernel memory available. This will probably not work if the dump is just a
>minidump.
>
>!process 1 (@$proc represents the current process) Then,
>!token on the token pointer displayed to get the SID.

OK, great this pointed me in the right direction, however i used !thread to get
the PEB, then !process to get the token, then !token to get to the SID. I then
used wbinfo(1) (from samba) to convert the SID to username. BINGO! Worked
perfectly!

Is it possible to convert the SID to username within windbg ?

Also, in the command “!process 1” what does refer to ?

-Alex

IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email.

5

Alex,

The Windows kernel defines the _EPROCESS structure to represent the
“process” concept under Windows. You can display this structure by typing
“dt nt!_EPROCESS” in the debugger (assuming that you are using the correct
symbols). You can display a list of “processes” by entering “!process 0 0”
in the debugger:

kd> !process 0 0
Unable to get program counter
**** NT ACTIVE PROCESS DUMP ****
PROCESS 847fa020 SessionId: none Cid: 0004 Peb: 00000000 ParentCid:
0000
DirBase: 00185000 ObjectTable: 89001c30 HandleCount: 554.
Image: System

PROCESS 85713c48 SessionId: none Cid: 00f8 Peb: 7ffdf000 ParentCid:
0004
DirBase: 76f08020 ObjectTable: 89189388 HandleCount: 29.
Image: smss.exe

PROCESS 8564fd40 SessionId: 0 Cid: 015c Peb: 7ffd5000 ParentCid: 0140
DirBase: 76f08060 ObjectTable: 9008a2c0 HandleCount: 531.
Image: csrss.exe

If you look at the output from the preceding command you see a pointer
displayed right after the text “PROCESS.” This is a pointer to an EPROCESS
block. So you can do the following:

kd> !process 8564fd40 1
Unable to get program counter
PROCESS 8564fd40 SessionId: 0 Cid: 015c Peb: 7ffd5000 ParentCid: 0140
DirBase: 76f08060 ObjectTable: 9008a2c0 HandleCount: 531.
Image: csrss.exe
VadRoot 85cdbc00 Vads 91 Clone 0 Private 272. Modified 504. Locked 0.
DeviceMap 890089e8
Token 9007bcf8
ElapsedTime 3 Days 19:07:25.895
UserTime 00:00:00.000
KernelTime 00:00:02.093
QuotaPoolUsage[PagedPool] 0
QuotaPoolUsage[NonPagedPool] 0
Working Set Sizes (now,min,max) (669, 50, 345) (2676KB, 200KB, 1380KB)
PeakWorkingSetSize 734
VirtualSize 35 Mb
PeakVirtualSize 36 Mb
PageFaultCount 1561
MemoryPriority BACKGROUND
BasePriority 13
CommitCharge 544

The “1” is a flag which indicates how much information to display. You can
omit the flag for a more verbose display.

Regards,

Rossetoecioccolato.

6

0n Tue, Feb 15, 2011 at 06:29:41AM -0500, George M. Garner Jr. wrote:

If you look at the output from the preceding command you see a pointer
>displayed right after the text “PROCESS.” This is a pointer to an EPROCESS
>block. So you can do the following:
>
>kd> !process 8564fd40 1

Great, thanks for that explanation!

One question about this: The pointer to the EPROCESS block - is it correct to
think of this as the entry point of a process ?

-Alex

IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email.

7

Alex,

One question about this: The pointer to the EPROCESS block - is it
correct to think of this as the entry point of a process ? <

No. A “process” is basically a collection of resources under Windows
(address space, handle table, module list, thread list, etc.). The EPROCESS
block is a bit of metadata describing (and collecting) those resources.
“Threads” describe a unit of execution and related resources. They have a
StartAddress and (usually) a Win32StartAddress. Process modules also each
have an entry point. Perhaps you might consider the Win32StartAddress of
the first thread to be the process entry point. Or you could consider the
entry point of the first (main) module to be the process entry point.

Try the following sequence of commands to display verbose information about
a process and its user modules:

.process /p /r
!process
lm u

The second command displays information about a process, including its
threads and a stack backtrace for each thread. The first command sets the
process context to the selected process and makes the interpretation of user
mode components more reliable. The thread StartAddress and
Win32StartAddress can be manipulated for malicious purposes, including to
obfuscate the real start address after execution.

!analyze -v is a good place to start if you haven’t done that already.

Getting back to your question about the UID of a running process, you also
have to consider the UID of the thread that caused the crash since the
thread may be impersonating someone other thant the UID of the process.

Regards,

Rossetoecioccolato.