Breakpoint in user mode code during kernel debugging

[Shatilo@discussions.microsoft.com Al Shatilo]

I am doing kernel debugging of a target computer. I want put breakpoint into code of some user mode application.

1. I break debugger in context of user mode process. I am using breakpoint inside kernel mode driver that process some IOCTL from this user mode process. Then I reload symbols for user mode process, switch to its source in calls window and set breakpoint.
Breakpoint works fine.

2. I break debugger not in context of user mode process. I am just press “Break” button on WinDbg toolbar. I am using following sequence of commands to set breakpoint:
- .cache forcedecodeuser
- .process <user mode process address>
-.reload /user
(Obviously the three commands above could be replaced by .process <address> /p /r)
- Then I set breakpoint inside source of user mode process. WinDbg indicate that breakpoint is set (it highlight breakpoint).
- Then I press g (Go) but breakpoint never fire.

How to set breakpoint correctly on user mode code from arbitrary context?

[Ivan Brugiolo [MSFT]]

can you try

kd>.process /p EPROCESS ADDRESS

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Al Shatilo" <Al Sha...@discussions.microsoft.com> wrote in message
news:0FAB6E74-38EA-43FE...@microsoft.com...

[Shatilo@discussions.microsoft.com Al Shatilo]

I have done following steps:
1. kd>.process /p EPROCESS ADDRESS
2. kd>.reload /user
3. Than I switched to sources
4. I set breakpoint on some line that always executed. WinDbg highlight that line.
6. kd> g

Breakpoint never fire. Hence result is same and should be same.
Because .cache forcedecodeuser implicitly called
by .process /p EPROCESS ADDRESS.
BTW, my appliction is NT Service that communicating with kernel driver.

[Ivan Brugiolo [MSFT]]

Just to be sure, did you do something like

kd> x ntdll!RtlAllocateHeap
00000000`77f355a0 ntdll!RtlAllocateHeap (void *, unsigned long, unsigned
int64)
kd> !process -1 0
PROCESS fffffadff3962040
SessionId: 0 Cid: 0250 Peb: 7fffffd5000 ParentCid: 0224
DirBase: 1de65000 ObjectTable: fffffa80001cca20 HandleCount: 241.
Image: services.exe

kd> x ntdll!RtlAllocateHeap
00000000`77f355a0 ntdll!RtlAllocateHeap (void *, unsigned long, unsigned
int64)
kd> bp /p fffffadff3962040 00000000`77f355a0
kd> g
Breakpoint 0 hit
ntdll!RtlAllocateHeap:
0033:00000000`77f355a0 4c89442418 mov [rsp+0x18],r8
kd> !process -1 0
PROCESS fffffadff3962040
SessionId: 0 Cid: 0250 Peb: 7fffffd5000 ParentCid: 0224
DirBase: 1de65000 ObjectTable: fffffa80001cca20 HandleCount: 241.
Image: services.exe

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Al Shatilo" <Al Sha...@discussions.microsoft.com> wrote in message

news:047BFF55-76F9-4838...@microsoft.com...

[Al Shatilo]

I did following sequence:
1. kd> !process 0 0
From output of the command I took required EPROCESS ADDRESS

2. kd>.process /p /r EPROCESS ADDRESS
I set user mode process context and load it symbols

3. kd> x mymodule!myfunction
Get address of myfunction. Let`s call it myfunction_address.

4. kd> bp /p EPROCESS ADDRESS myfunction_address
or
4. kd> bp myfunction_address
No matter which kind of breakpoint is used.

5. kd> g
Breakpoint never fire.

I found solution but only for XP and later.
We should use .process /i EPROCESS ADDRESS.

[Ivan Brugiolo [MSFT]]

Was that function mapped in the target process address space ?
And, which OS is this happening ?

the "WinXP" solution seems an invasive process switch,
that is the forcefull way to get the debugger to have the "switched-to"
process context
as the current context.

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Al Shatilo" <AlSh...@discussions.microsoft.com> wrote in message
news:6683F560-B7A2-4E08...@microsoft.com...

[Al Shatilo]

Hello Ivan,

1. Yes, that function was mapped in the target process address space.
2. I am using Windows XP and Windows 2000 as well.
Behavior is same for all OS listed above.
3. I am using latest available WinDbg version 6.3.0017.0.

Regards,
Al

[Ivan Brugiolo [MSFT]]

Can you provide some repro steps ?

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Al Shatilo" <AlSh...@discussions.microsoft.com> wrote in message

news:312F28CD-2E8A-4B5A...@microsoft.com...

[Al Shatilo]

1. Run Target computer with XP Service Pack 1.
2. Run on Target computer RegEdit.
3. Highlight HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services using mouse.
4. Run WinDbg on Host computer.
5. Connect WinDbg to target (I prefer FireWire connection).
6. Then our usual steps:
kd> !process 0 0
**** NT ACTIVE PROCESS DUMP ****
PROCESS 81bce7c8 SessionId: none Cid: 0004 Peb: 00000000 ParentCid: 0000
DirBase: 00039000 ObjectTable: e1000d20 HandleCount: 313.
Image: System

PROCESS 81acea68 SessionId: none Cid: 01c8 Peb: 7ffdf000 ParentCid: 0004
DirBase: 0860c000 ObjectTable: e10069b0 HandleCount: 21.
Image: smss.exe

PROCESS 819acd80 SessionId: 0 Cid: 01f8 Peb: 7ffdf000 ParentCid: 01c8
DirBase: 098d3000 ObjectTable: e14f00f8 HandleCount: 288.
Image: csrss.exe

PROCESS 819b8da8 SessionId: 0 Cid: 0210 Peb: 7ffdf000 ParentCid: 01c8
DirBase: 09db8000 ObjectTable: e14d83e8 HandleCount: 517.
Image: winlogon.exe

PROCESS 819d6da8 SessionId: 0 Cid: 0244 Peb: 7ffdf000 ParentCid: 0210
DirBase: 0a209000 ObjectTable: e17c8998 HandleCount: 258.
Image: services.exe

PROCESS 819dc868 SessionId: 0 Cid: 0250 Peb: 7ffdf000 ParentCid: 0210
DirBase: 0a23a000 ObjectTable: e17c8a90 HandleCount: 286.
Image: lsass.exe

PROCESS 819a3d80 SessionId: 0 Cid: 030c Peb: 7ffdf000 ParentCid: 0244
DirBase: 0abb0000 ObjectTable: e18114f0 HandleCount: 217.
Image: svchost.exe

PROCESS 819d2cc0 SessionId: 0 Cid: 036c Peb: 7ffdf000 ParentCid: 0244
DirBase: 0ad28000 ObjectTable: e1811258 HandleCount: 1064.
Image: svchost.exe

PROCESS 819fe4a8 SessionId: 0 Cid: 03d8 Peb: 7ffdf000 ParentCid: 0244
DirBase: 0bdd7000 ObjectTable: e1823d90 HandleCount: 58.
Image: svchost.exe

PROCESS 819d0020 SessionId: 0 Cid: 0410 Peb: 7ffdf000 ParentCid: 0244
DirBase: 0bfbf000 ObjectTable: e17c7ea0 HandleCount: 227.
Image: svchost.exe

PROCESS 819c5818 SessionId: 0 Cid: 04b0 Peb: 7ffdf000 ParentCid: 0244
DirBase: 0c86e000 ObjectTable: e1a80c18 HandleCount: 111.
Image: spoolsv.exe

PROCESS 8176fae0 SessionId: 0 Cid: 0720 Peb: 7ffdf000 ParentCid: 06f4
DirBase: 0da84000 ObjectTable: e1b77838 HandleCount: 355.
Image: explorer.exe

PROCESS 816e13a8 SessionId: 0 Cid: 07b0 Peb: 7ffdf000 ParentCid: 0720
DirBase: 0e802000 ObjectTable: e1c93048 HandleCount: 59.
Image: atiptaxx.exe

PROCESS 816dcbe8 SessionId: 0 Cid: 07bc Peb: 7ffdf000 ParentCid: 0720
DirBase: 0eb7f000 ObjectTable: e181f328 HandleCount: 99.
Image: mixer.exe

PROCESS 816dc020 SessionId: 0 Cid: 07c4 Peb: 7ffdf000 ParentCid: 0720
DirBase: 0ebbf000 ObjectTable: e1a1a468 HandleCount: 54.
Image: ctfmon.exe

PROCESS 816d9020 SessionId: 0 Cid: 07cc Peb: 7ffdf000 ParentCid: 0720
DirBase: 0ebf2000 ObjectTable: e1a058d8 HandleCount: 309.
Image: msmsgs.exe

PROCESS 8174f610 SessionId: 0 Cid: 01e4 Peb: 7ffdf000 ParentCid: 0720
DirBase: 00364000 ObjectTable: e1b551a8 HandleCount: 191.
Image: mmc.exe

PROCESS 816de020 SessionId: 0 Cid: 03cc Peb: 7ffdf000 ParentCid: 036c
DirBase: 07853000 ObjectTable: e150e378 HandleCount: 99.
Image: wuauclt.exe

PROCESS 817822c8 SessionId: 0 Cid: 0690 Peb: 7ffdf000 ParentCid: 0720
DirBase: 00831000 ObjectTable: e1bb0b30 HandleCount: 37.
Image: regedit.exe

kd> .process /p /r 817822c8
Implicit process is now 817822c8
.cache forcedecodeuser done
Loading User Symbols
.Loading symbols for 01000000 regedit.exe ->
ModLoad: 01000000 01063000 F:\WINDOWS\regedit.exe
.Loading symbols for 77f50000 ntdll.dll -> ntdll.dll
ModLoad: 77f50000 77ff7000 F:\WINDOWS\System32\ntdll.dll
.Loading symbols for 77e60000 kernel32.dll -> kernel32.dll
ModLoad: 77e60000 77f46000 F:\WINDOWS\system32\kernel32.dll
.Loading symbols for 77c10000 msvcrt.dll -> msvcrt.dll
ModLoad: 77c10000 77c63000 F:\WINDOWS\system32\msvcrt.dll
.Loading symbols for 77dd0000 ADVAPI32.dll ->
ModLoad: 77dd0000 77e5d000 F:\WINDOWS\system32\ADVAPI32.dll
.Loading symbols for 78000000 RPCRT4.dll ->
ModLoad: 78000000 78087000 F:\WINDOWS\system32\RPCRT4.dll
.Loading symbols for 7e090000 GDI32.dll -> GDI32.dll
ModLoad: 7e090000 7e0d1000 F:\WINDOWS\system32\GDI32.dll
.Loading symbols for 77d40000 USER32.dll -> USER32.dll
ModLoad: 77d40000 77dcc000 F:\WINDOWS\system32\USER32.dll
.Loading symbols for 71950000 COMCTL32.dll -> COMCTL32.dll
ModLoad: 71950000 71a34000 F:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.1331_x-ww_7abf6d02\COMCTL32.dll
.Loading symbols for 70a70000 SHLWAPI.dll -> SHLWAPI.dll
ModLoad: 70a70000 70ad5000 F:\WINDOWS\system32\SHLWAPI.dll
.Loading symbols for 763b0000 comdlg32.dll -> comdlg32.dll
ModLoad: 763b0000 763f5000 F:\WINDOWS\system32\comdlg32.dll
.Loading symbols for 773d0000 SHELL32.dll -> SHELL32.dll
ModLoad: 773d0000 77bc9000 F:\WINDOWS\system32\SHELL32.dll
.Loading symbols for 76cc0000 AUTHZ.dll -> AUTHZ.dll
ModLoad: 76cc0000 76cd0000 F:\WINDOWS\System32\AUTHZ.dll
.Loading symbols for 71550000 ACLUI.dll -> ACLUI.dll
ModLoad: 71550000 7156d000 F:\WINDOWS\System32\ACLUI.dll
.Loading symbols for 771b0000 ole32.dll -> ole32.dll
ModLoad: 771b0000 772d4000 F:\WINDOWS\system32\ole32.dll
.Loading symbols for 77120000 OLEAUT32.dll ->
ModLoad: 77120000 771ab000 F:\WINDOWS\system32\OLEAUT32.dll
.Loading symbols for 71fa0000 ulib.dll -> ulib.dll
ModLoad: 71fa0000 71fe4000 F:\WINDOWS\System32\ulib.dll
.Loading symbols for 6f2b0000 clb.dll -> clb.dll
ModLoad: 6f2b0000 6f2b6000 F:\WINDOWS\System32\clb.dll
.Loading symbols for 5ad70000 uxtheme.dll -> uxtheme.dll
ModLoad: 5ad70000 5ada4000 F:\WINDOWS\System32\uxtheme.dll
.Loading symbols for 74720000 MSCTF.dll -> MSCTF.dll
ModLoad: 74720000 74764000 F:\WINDOWS\System32\MSCTF.dll

kd> x regedit!RegEdit_OnContextMenu
01004547 regedit!RegEdit_OnContextMenu = <no type information>

kd> bp /p 817822c8 01004547

kd> bl
0 e 01004547 0001 (0001) regedit!RegEdit_OnContextMenu
Match process data 817822c8
kd> g

7. Click right mouse button to display context menu in Regedit.

Breakpoint never fire.

Additional information:
kd> version
Windows XP Kernel Version 2600 (Service Pack 1) UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp2.030422-1633
Kernel base = 0x804d4000 PsLoadedModuleList = 0x80543530
Debug session time: Wed Jun 30 09:24:59 2004
System Uptime: 0 days 0:18:16.086
Remote KD: KdSrv:Server=@{<Local>},Trans=@{1394:Channel=44}
command line: 'D:\WinDbg\windbg.exe -k 1394:channel=44 -b -QY -QSY -n -v -c "$<D:\WinDbgData\Scripts\Common.wds"' Debugger Process 0x4E8
dbgeng: image 6.3.0017.0, built Tue May 25 02:27:51 2004
[path: D:\WinDbg\dbgeng.dll]
dbghelp: image 6.3.0017.0, built Tue May 25 02:28:03 2004
[path: D:\WinDbg\dbghelp.dll]
DIA version: 40416
Extension DLL search Path:
D:\WinDbg\winext;D:\WinDbg\winext\arcade;D:\WinDbg\WINXP;D:\WinDbg\pri;D:\WinDbg;D:\WinDbg\winext\arcade;C:\WINNT\system32;C:\WINNT;C:\WINNT\system32\WBEM;D:\Perl\bin\;D:\VC\bin;C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem;D:\NTDDK.4\bin;D:\MVS\Common\Tools\WinNT;D:\MVS\VC98\Bin;D:\MVS\Common\Tools;D:\MVS\Common\MSDev98\Bin;c:\bin;D:\MSSDK\Bin\.;D:\MSSDK\Bin\WinNT\.;D:\ntice;C:\Tcl\bin;C:\Program Files\Common Files\Compuware\NMShared;C:\Program Files\UltraEdit;D:\MVS\Common\Tools\WinNT;D:\MVS\Common\MSDev98\Bin;D:\MVS\Common\Tools;D:\MVS\VC98\bin;D:\MSSDK\Bin\.;D:\MSSDK\Bin\WinNT\.
Extension DLL chain:
dbghelp: image 6.3.0017.0, API 6.0.6, built Tue May 25 02:28:03 2004
[path: D:\WinDbg\dbghelp.dll]
ext: image 6.3.0017.0, API 1.0.0, built Tue May 25 20:23:08 2004
[path: D:\WinDbg\winext\ext.dll]
exts: image 6.3.0017.0, API 1.0.0, built Tue May 18 21:23:14 2004
[path: D:\WinDbg\WINXP\exts.dll]
kext: image 6.3.0017.0, API 1.0.0, built Tue May 18 21:23:16 2004
[path: D:\WinDbg\winext\kext.dll]
kdexts: image 6.0.4071.0, API 1.0.0, built Tue May 11 03:12:47 2004
[path: D:\WinDbg\WINXP\kdexts.dll]

The same breakpoint fire if I am using .process /i 817822c8.

"Ivan Brugiolo [MSFT]" wrote:

> ..process

[R. Green]

Hi,

I have exactly the same problem.
I have reported of it in post "Setting breakpoints in user space"

"Al Shatilo" <Al Sha...@discussions.microsoft.com> wrote in message
news:0FAB6E74-38EA-43FE...@microsoft.com...

[Al Shatilo]

Hello Ivan,

Please, provide feedback.
Is the bug confirmed? When it will be fixed?

Best regards,
Al

[Ivan Brugiolo [MSFT]]

I can get this to work as well.
If you are in the context od the process (.process /i /p EPROCESS),
and you set an un-conditional breakpoint over there, does it work more
reliably ?

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Al Shatilo" <AlSh...@discussions.microsoft.com> wrote in message

news:8014EB01-CD47-4DA4...@microsoft.com...

[Al Shatilo]

Hello Ivan,

> I can get this to work as well.

But in my example with RegEdit.exe breakpoint never fired. Did you break debugger in arbitrary context, i.e. not in context of RegEdit.exe? By the way, other people report the same problem.

> If you are in the context od the process (.process /i /p EPROCESS),
> and you set an un-conditional breakpoint over there, does it work more
> reliably ?
>

The un-conditional breakpoint after command ‘.process /i /p EPROCESS’ works perfect. But ‘.process /i EPROCESS’ command only for Windows XP and later, therefore can’t be used for Windows 2000.

Best regards,

[Ivan Brugiolo [MSFT]]

User mode breakpoint set from kernel has a very different mileage in
different platforms.
That's why the "/i" options was added to .process.
In W2K, there's a collection of trickes to simulate the behavior
(they all revolve around setting break-point on address on the EPROCESS
structure that are hit when the kernel has "attached" the user-context,
mainly MemoryManager structures).
That's why "ntsd -d" is normally your best friend.
You can do a ".breakin" from ntsd, get back to kenrel, find the target
process, and,
inspect the context from there.

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Al Shatilo" <AlSh...@discussions.microsoft.com> wrote in message

news:0225C494-41A0-4B5A...@microsoft.com...

[Al Shatilo]

Hello Ivan,

Thanks a lot. Finally, I got the answer.