USB drivers for Win 7 on 8th generation Intel chipset

[WaxfordSqueers]

I guess what's confusing me is I don't see GetMessageW in the list of imports in IDA in either mmc.exe or devmgr.dll. You must have a secret trick.

Heh!!!

No trick of mine it all comes down to the code snippet to break on a message box OK button.

bp user32!GetMessageW "pt;gc"
g
bc *
.load sdbgext
bp @eip ".if (poi(poi(esp+4)+4) == 0x202) {!hwnd poi(poi(esp+4));gc } .else {gc}"
g

I could not get the extension sdbgext to work in w64 therefore could not employ the !hwnd poi(poi(esp+4)). However, the bp user32!GetMessageW "pt;gc" got me right into the message loop for windows and it was retrieving messages from Device Manager (I presume devmgr.dll).

I know the message loop processes all messages from user apps but when I was there it was processing only device manager windows messages. Many of them we 0xf messages for wm_paint.

I guess because I was in the context for Device Manager when I activated the OK button, windows must have retrieved the message. It was a 32770 dialog box.

https://docs.microsoft.com/en-us/windows/desktop/winmsg/about-window-classes

I may be all wet but it is my understanding that the window's message loop uses getmessagew and that it is a system thing. It processes any windows message and passes it on to the calling application.

Looked it up:

https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-getmessagew

GetMessageW function

Retrieves a message from the calling thread's message queue. The function dispatches incoming sent messages until a posted message is available for retrieval.

[Kayaker]

I guess you found a message loop at some level, a system wide message queue? I didn't think that breakpoint would work if the API wasn't called as an import in what seemed to be the main code processes. The stack might clear up exactly what code you're sitting in.

I believe breakpoints should be process specific with this format.

r $proc
.process

bp /p @$proc user32!GetMessageW

[WaxfordSqueers]

kayaker...here's how to reproduce:

-control panel\device manager

-in devmgr go to top of tree at user name, right click and select Install Legacy Hardware.

-hit 'next' and on next window choose to install manually.

-next window is Add Hardware window. I go down to USB and select an Intel USB 3 host controller driver.

-select driver then 'Have Disk'. Find driver in that set of Intel drivers to which I linked earlier.

-a 32770 dialog box opens with OK button.

-open windbg as Administrator.

-select 'Attach to Process'

-look down list for mmc then select it.

-windbg opens mmc.

-break (not really sure if I used break)

-I run .reload force /f

-trick here is to arrange windows so that the mouse can be placed over the OK button on dev manager 32770 box. Once you set bp user32!getmessagew it will break on even a mouse movement.

-enter bp user32!getmessagew in wdbg and hit 'enter'

-very carefully go to mouse and do a left click. Dev manager window should break up and wdbg should break at 77539e54 push rebx

-a few lines below there is an official call to user32!getmessagew+0x1b

Tracing a few steps reveals hwnd of "Device Manager" MMCMainFrame in rsi.

Tracing blindly a lot further there is a call to mmc!CSubclassManager::SubClasProc

The call is at 77539bb6 in user32!UserCallWinProcCheckWow+0x1ad and the mmcfunc is at ff4f2474. IDA shows the func at .text:01009DAF.

stack:

# Child-SP RetAddr Call Site
00 00000000`0018cc18 000007fe`fb955925 USER32!GetMessageW
01 00000000`0018cc20 000007fe`fb955cfd Comctl32!_RealPropertySheet+0x309
02 00000000`0018ccf0 000007fe`e61a8b15 Comctl32!_PropertySheet+0x55
03 00000000`0018cd30 000007fe`e61a2204 hdwwiz!PropertySheetW+0x55
04 00000000`0018cd60 000007fe`ee213a94 hdwwiz!AddHardwareWizard+0x130
05 00000000`0018d8f0 000007fe`ee2131d7 devmgr!CResultView::MenuCommand+0x2e0
06 00000000`0018d950 000007fe`ee20fb2a devmgr!CFolder::MenuCommand+0xab
07 00000000`0018d980 000007fe`e4b71a33 devmgr!CComponent::Command+0x92
08 00000000`0018d9e0 000007fe`e4abbc6f mmcndmgr!IExtendContextMenuWrapper::Command+0xeb
09 00000000`0018db20 000007fe`e4a9d260 mmcndmgr!CMenuItem::ScExecute+0x367
0a 00000000`0018dbe0 000007fe`e4a9ca90 mmcndmgr!CContextMenu::ExecuteMenuItem+0xd4
0b 00000000`0018dc50 000007fe`e4a9c840 mmcndmgr!CContextMenu::ShowContextMenuEx+0x244
0c 00000000`0018dd40 000007fe`e4a98e20 mmcndmgr!CContextMenu::ShowContextMenu+0x20
0d 00000000`0018dd90 000007fe`e4b7e023 mmcndmgr!CNodeInitObject::ShowContextMenu+0x128
0e 00000000`0018de10 000007fe`ee214dfb mmcndmgr!NodeInitObjectWrapper::IContextMenuProviderWrapper::ShowContextMenu+0xbf
0f 00000000`0018df30 000007fe`ee20b4aa devmgr!CResultView:oContextMenu+0x1c7
10 00000000`0018dfd0 000007fe`ee20880a devmgr!CResultView::tvNotify+0xdd
11 00000000`0018e000 000007fe`ee208134 devmgr!CFolder::tvNotify+0x26
12 00000000`0018e040 000007fe`e6503dfe devmgr!CComponent::tvNotify+0x58
13 00000000`0018e080 000007fe`e5f90c4a dmocx!CTVCtrl::OnContextMenu+0x82

Code:

USER32!GetMessageW:
00000000`77539e54 fff3            push    rbx
00000000`77539e56 4883ec20        sub     rsp,20h
00000000`77539e5a 418bc0          mov     eax,r8d
00000000`77539e5d 488bd9          mov     rbx,rcx
00000000`77539e60 b90000feff      mov     ecx,0FFFE0000h
00000000`77539e65 410bc1          or      eax,r9d
00000000`77539e68 458bd1          mov     r10d,r9d
00000000`77539e6b 85c1            test    ecx,eax
00000000`77539e6d 0f85678d0100    jne     USER32!GetMessageW+0x1b (00000000`77552bda)
00000000`77539e73 458bca          mov     r9d,r10d
00000000`77539e76 488bcb          mov     rcx,rbx
00000000`77539e79 e8c2ffffff      call    USER32!NtUserGetMessage (00000000`77539e40)
00000000`77539e7e 817b0802010000  cmp     dword ptr [rbx+8],102h
00000000`77539e85 448bd0          mov     r10d,eax
00000000`77539e88 0f844e480000    je      USER32!GetMessageW+0x49 (00000000`7753e6dc)
00000000`77539e8e 817b08cc000000  cmp     dword ptr [rbx+8],0CCh
00000000`77539e95 0f8441480000    je      USER32!GetMessageW+0x49 (00000000`7753e6dc)
00000000`77539e9b 418bc2          mov     eax,r10d
00000000`77539e9e 4883c420        add     rsp,20h
00000000`77539ea2 5b              pop     rbx
00000000`77539ea3 c3              ret

[WaxfordSqueers]

kayaker....there is a reply just before this one.

Trying to repeat my last process in wdbg u-mode in remote kernel debugging. No success thus far. Below is a list of U-mode processes from my host. You can see mmc.exe listed along with devmgr.dll and hdwwiz, a reference to the Hardware Wizard window. Although they show symbols as being deferred, I have managed to load symbols for all of them using the ld command.

There seems to be no communication whatsoever between host and any u-mode apps. Whereas that may be by design, if it is the case, it pretty well renders wdbg useless as a debugger other than for drivers.

My overall impression is that wdbg gives loads of information about windows features but it's not even half the debugger of softice. I could go anywhere in ring 0 with sice but I have yet to get beyond ntdll with wdbg. There was no need for remote debugging with sice, it could all be done on the same computer, and powerfully.

Hope I am wrong.

0: kd> lm u
start end module name
00000000`022c0000 00000000`022c4000 api_ms_win_downlevel_shlwapi_l1_1_0 (deferred)
00000000`02620000 00000000`02acc000 WININET (deferred)
00000000`052f0000 00000000`0532b000 WINTRUST (deferred)
00000000`73c60000 00000000`73c98000 odbcint (deferred)
00000000`77420000 00000000`7751a000 USER32 (pdb symbols) c:\websymbols\user32.pdb\9A43D3FD584F4A9698B7AB8D28BC8C502\user32.pdb
00000000`77520000 00000000`7763f000 kernel32 (deferred)
00000000`77640000 00000000`777df000 ntdll (pdb symbols) c:\websymbols\ntdll.pdb\15FC8206E55A4725A768F3033BB4C9201\ntdll.pdb
00000000`777e0000 00000000`777e3000 normaliz (deferred)
00000000`777f0000 00000000`777f7000 PSAPI (deferred)
00000000`ffc20000 00000000`ffe30000 mmc (deferred)
000007fe`e3a00000 000007fe`e3d14000 mmcndmgr (deferred)
000007fe`e42c0000 000007fe`e4397000 SearchFolder (deferred)
000007fe`e4650000 000007fe`e47a0000 MFC42u (deferred)
000007fe`e47c0000 000007fe`e47fb000 mlang (deferred)
000007fe`e4800000 000007fe`e4883000 devmgr (deferred)
000007fe`e4890000 000007fe`e48ea000 mmcbase (deferred)
000007fe`e4b90000 000007fe`e4baf000 thumbcache (deferred)
000007fe`e4bb0000 000007fe`e4c2b000 StructuredQuery (deferred)
000007fe`e6de0000 000007fe`e6df1000 dmocx (deferred)
000007fe`e7180000 000007fe`e71bf000 hdwwiz (deferred)
000007fe`e71c0000 000007fe`e7211000 newdev (deferred)
000007fe`e7610000 000007fe`e76ca000 ieproxy (deferred)
000007fe`e7920000 000007fe`e7924000 api_ms_win_downlevel_shlwapi_l2_1_0 (deferred)
000007fe`e8e80000 000007fe`e8f31000 ODBC32 (deferred)
000007fe`e91e0000 000007fe`ea07a000 ieframe (deferred)
000007fe`ea150000 000007fe`ea154000 api_ms_win_downlevel_shell32_l1_1_0 (deferred)
000007fe`ea180000 000007fe`ea355000 msxml3 (deferred)
000007fe`eeff0000 000007fe`ef024000 SHDOCVW (deferred)
000007fe`ef330000 000007fe`ef41e000 actxprxy (deferred)
000007fe`f6e10000 000007fe`f6e74000 webio (deferred)
000007fe`f6e80000 000007fe`f6ef1000 WINHTTP (deferred)
000007fe`f7610000 000007fe`f7614000 api_ms_win_downlevel_advapi32_l2_1_0 (deferred)
000007fe`f7710000 000007fe`f7718000 IconCodecService (deferred)
000007fe`f7720000 000007fe`f77a0000 ntshrui (deferred)
000007fe`f77a0000 000007fe`f77af000 CSCAPI (deferred)
000007fe`f77b0000 000007fe`f77bc000 CSCDLL (deferred)
000007fe`f77c0000 000007fe`f783e000 cscui (deferred)
000007fe`f7840000 000007fe`f7875000 EhStorShell (deferred)
000007fe`f8160000 000007fe`f816b000 slc (deferred)
000007fe`f8c60000 000007fe`f8dc1000 WindowsCodecs (deferred)
000007fe`f91d0000 000007fe`f91e8000 dwmapi (deferred)
000007fe`fa2f0000 000007fe`fa333000 DUser (deferred)
000007fe`fa340000 000007fe`fa432000 DUI70 (deferred)
000007fe`fa660000 000007fe`fa6b6000 UxTheme (deferred)
000007fe`fab50000 000007fe`fac7c000 propsys (deferred)
000007fe`faf50000 000007fe`faf77000 cryptnet (deferred)
000007fe`fb250000 000007fe`fb2f0000 COMCTL32_7fefb250000 (deferred)
000007fe`fb610000 000007fe`fb645000 xmllite (deferred)
000007fe`fbb40000 000007fe`fbb6d000 ntmarta (deferred)
000007fe`fbfa0000 000007fe`fbfbb000 GPAPI (deferred)
000007fe`fbfc0000 000007fe`fbfd2000 devrtl (deferred)
000007fe`fbfe0000 000007fe`fbfff000 SPINF (deferred)
000007fe`fc190000 000007fe`fc1d7000 rsaenh (deferred)
000007fe`fc490000 000007fe`fc4a8000 CRYPTSP (deferred)
000007fe`fc5a0000 000007fe`fc5ec000 bcryptprimitives (deferred)
000007fe`fc650000 000007fe`fc672000 bcrypt (deferred)
000007fe`fc680000 000007fe`fc6a3000 srvcli (deferred)
000007fe`fc6b0000 000007fe`fc700000 ncrypt (deferred)
000007fe`fc910000 000007fe`fc91b000 Secur32 (deferred)
000007fe`fcab0000 000007fe`fcab9000 fltlib (deferred)
000007fe`fcac0000 000007fe`fcacc000 version (deferred)
000007fe`fcb10000 000007fe`fcbfa000 guard64 (deferred)
000007fe`fcc30000 000007fe`fcc84000 oleacc (deferred)
000007fe`fcc90000 000007fe`fce85000 Comctl32 (deferred)
000007fe`fcf10000 000007fe`fcf35000 SSPICLI (deferred)
000007fe`fcf40000 000007fe`fcf97000 apphelp (deferred)
000007fe`fcfa0000 000007fe`fcfaf000 CRYPTBASE (deferred)
000007fe`fcfb0000 000007fe`fd041000 SXS (deferred)
000007fe`fd050000 000007fe`fd064000 RpcRtRemote (deferred)
000007fe`fd070000 000007fe`fd073000 api_ms_win_core_synch_l1_2_0 (deferred)
000007fe`fd080000 000007fe`fd0eb000 cssguard64 (deferred)
000007fe`fd190000 000007fe`fd19f000 profapi (deferred)
000007fe`fd1a0000 000007fe`fd1af000 MSASN1 (deferred)
000007fe`fd1b0000 000007fe`fd1b4000 api_ms_win_downlevel_version_l1_1_0 (deferred)
000007fe`fd1c0000 000007fe`fd32d000 CRYPT32 (deferred)
000007fe`fd330000 000007fe`fd334000 api_ms_win_downlevel_ole32_l1_1_0 (deferred)
000007fe`fd340000 000007fe`fd344000 api_ms_win_downlevel_user32_l1_1_0 (deferred)
000007fe`fd350000 000007fe`fd3ba000 KERNELBASE (deferred)
000007fe`fd410000 000007fe`fd413000 api_ms_win_downlevel_normaliz_l1_1_0 (deferred)
000007fe`fd4c0000 000007fe`fd4c5000 api_ms_win_downlevel_advapi32_l1_1_0 (deferred)
000007fe`fd4d0000 000007fe`fd506000 CFGMGR32 (deferred)
000007fe`fd510000 000007fe`fd52e000 USERENV (deferred)
000007fe`fd530000 000007fe`fd54a000 DEVOBJ (deferred)
000007fe`fd550000 000007fe`fd5a2000 WLDAP32 (deferred)
000007fe`fd5b0000 000007fe`fd67b000 USP10 (deferred)
000007fe`fd680000 000007fe`fd717000 COMDLG32 (deferred)
000007fe`fdbd0000 000007fe`fdc37000 GDI32 (deferred)
000007fe`fdc40000 000007fe`fdcdf000 msvcrt (deferred)
000007fe`fdce0000 000007fe`fdd51000 SHLWAPI (deferred)
000007fe`fdd70000 000007fe`fdf6f000 ole32 (deferred)
000007fe`fdf70000 000007fe`fe079000 MSCTF (deferred)
000007fe`fe120000 000007fe`fe12e000 LPK (deferred)
000007fe`fe130000 000007fe`fe2b8000 urlmon (deferred)
000007fe`fe310000 000007fe`ff09a000 SHELL32 (deferred)
000007fe`ff0a0000 000007fe`ff17b000 ADVAPI32 (deferred)
000007fe`ff180000 000007fe`ff2ac000 RPCRT4 (deferred)
000007fe`ff2b0000 000007fe`ff38a000 OLEAUT32 (deferred)
000007fe`ff390000 000007fe`ff3be000 IMM32 (deferred)
000007fe`ff3c0000 000007fe`ff3df000 sechost (deferred)
000007fe`ff3e0000 000007fe`ff479000 CLBCatQ (deferred)
000007fe`ff480000 000007fe`ff74a000 iertutil (deferred)
000007fe`ff750000 000007fe`ff927000 SETUPAPI (deferred)

[WaxfordSqueers]

kayaker...spoke too soon...as usual.

Now blabbs will be mad at me.

Found a way but won't have a chance to test it right now.

I described the process before but here it is briefly. Need to get into the context of mmc.exe.

!process 0 0 mmc

Take the process address of mmc from above and add it to...

.process /i <address>.

wdbg instructs you to hit g and let target run. It claims when target breaks you will be in context of above.

Did that but got the following:

0: kd> .process /i fffffa8011f311e0
You need to continue execution (press 'g' <enter>) for the context
to be switched. When the debugger breaks in again, you will be in
the new process context.
0: kd> g
Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPointWithStatus:
fffff800`03ea2400 cc int 3
5: kd> gh
Breakpoint 1 hit
mmc!CSubclassManager::SubclassProc:
0033:00000000`ffc22474 fff7 push rdi

Note the 'Break instruction exception - code 80000003'

Gave me an idea and I hit 'Go Handled Exception' (hence the gh at kd> prompt). Following that the target broke at:

mmc!CSubclassManager::SubclassProc:
0033:00000000`ffc22474 fff7 push rdi

I am now in mmc code at a point I got to last night by setting the user32!getwindowsmesagew bp.

I had 3 bps set:

5: kd> bl
0 e 00000000`77439e54 0001 (0001) USER32!GetMessageW
1 e 00000000`ffc22474 0001 (0001) mmc!CSubclassManager::SubclassProc
2 e 00000000`77539bb6 0001 (0001) kernel32!BasepCreateActCtx+0xa17

The last one was an address I picked up somewhere.

Oddly enough, it did not break in user32. Maybe I have to set the context to U32 to have it hit but I can't seem to set the U32 context as I can the mmc context.

[WaxfordSqueers]

@kayaker...just noticed something I should have noticed before. In the particular implementation of Device Manager I am using, for manual hardware installation, the central app is setupapi. I had been looking for devmgr.dll but I am now thinking it may not even be called while installing hardware. Maybe deeper into the DM tree where drivers can be updated, devmgr may be implemented.

Thus far, I have gotten into the middle of setupapi from the host using kernel debugging and it is parsing the command line where I have my iusb3xhc USB3 driver.

The main problem I am having is extremely slow single stepping. It's the same problem with Windbg in user mode on the same machine so it does not seem to be the serial connection. It may be my antivirus since I noticed one of its components in the stack along with setupapi functions. I'll disable it next time but I wonder if disabling is enough since the driver remains loaded.

Here's an excerpt from setupapi where it is copying the command line as it checks for the disk source of the driver. Got here by manipulating the stack addresses and using them as bp's.

SETUPAPI!SetupPromptForDisk+0x70d:
0033:000007fe`ff7780fb 3bc2 cmp eax,edx
5: kd> t
SETUPAPI!SetupPromptForDisk+0x70f:
0033:000007fe`ff7780fd 0f87f16d0200 ja SETUPAPI!SetupPromptForDisk+0x711 (000007fe`ff79eef4)
5: kd> t
SETUPAPI!SetupPromptForDisk+0x718:
0033:000007fe`ff778103 4c8b842480000000 mov r8,qword ptr [rsp+80h]
5: kd> t
SETUPAPI!SetupPromptForDisk+0x720:
0033:000007fe`ff77810b e854a0fdff call SETUPAPI!StringCchCopyW (000007fe`ff752164)
5: kd> p
SETUPAPI!SetupPromptForDisk+0x725:
0033:000007fe`ff778110 85c0 test eax,eax
5: kd> t
SETUPAPI!SetupPromptForDisk+0x727:
0033:000007fe`ff778112 0f88e66d0200 js SETUPAPI!SetupPromptForDisk+0x729 (000007fe`ff79eefe)
5: kd> t

[Kayaker]

Yeah, I think that's zeroing in on it. I reached the same point by using Strings64 to scan the mui files in /system32/en-US for the error message when using the hardware wizard to try to install the usb driver, which pointed to setupapi.dll.mui.

The string resource Id is found with Resource Hacker, and a search in IDA showed exactly where the message dialog is created. I figure that function would be a place to start digging. Stepping back references an exported function called initially by devmgr.dll

File Name   : setupapi.dll

.text:000007FF79A83F84 SelectOEMDriver proc near               ; CODE XREF: SetupDiSelectOEMDrv+6E
.text:000007FF79A83F84                                         ; HandleSelectOEM+110

.text:000007FF79A84580                 mov     r8d, 0EA78h     ; 0x0000EA78,
.text:000007FF79A84580                                         ; "The folder you specified doesn't contain a compatible software driver for your device.
.text:000007FF79A84580                                         ;  If the folder contains a driver, make sure it is
.text:000007FF79A84580                                         ;  designed to work with %1.\r\n"
.text:000007FF79A84586                 mov     rdx, [rsp+208h+var_150]
.text:000007FF79A8458E                 mov     rcx, cs:MyDllModuleHandle
.text:000007FF79A84595                 call    FormatMessageBox

[WaxfordSqueers]

Stepping back references an exported function called initially by devmgr.dll

That's interesting and a whole lot easier than forcing my way through the deep code woods by tracing. Mind you, I have developed a few tricks over the years for managing immense amounts of code while tracing.

The check for the OEM driver is about where I am now.

I am not sure if this will accomplish anything but it's giving me practice with Windbg and allowing me to see how Windoze handles the installation of drivers. And what criteria it uses to determine whether the current driver is good enough, as it often claims. I am sure that comes down to reading the INF file, which as you pointed out, can be garnered from the Intel log file.

I am hoping to find out why it will install the driver under certain conditions yet not activate it. The Intel drivers to which I have posted a link were good for my type of mobo on W7 till very recently. Something may have changed in the B360 chipset model, which is not even listed in the INF file. It's reference is VEN_8080&DEV_A36D, the A36D referring to the B360 chipset USB 3 host controller.

The setup file checks for chipsets newer than Skylake (mine is Coffee Lake), which it references in the software as SKY+. I don't know if msoft has a similar check. It does know that I am using a newer chipset and processor and has cut me off from updates for W7. I regarded that as pretty mean-spirited.

I do know that Microsoft rates drivers and their acceptability using a scale. I have also noted that both Intel and Msoft have changed the dates on their drivers, Intel going back to 1969, the date of the formation of Intel. That seems to have something to do with the rating of drivers as well.

[WaxfordSqueers]

Kayaker...don't know if you have the answer for this or if blabberer might.

Windbg seems to lack the ability to trace into a system call. Typically, a system call begins with a 'syscall' and I expect the code to follow into the system itself. However, windbg seems to bypass system calls and that can result in undesirable effects when tracing code.

I reached a function in U32 called U32!_fnDWORD. From what I recall it is related to a callback from a system routine in U-mode.

Within that function there is another function:

0000000076F467FA call [User32!_imp_NtCallbackReturn]

It leads to the following code:

Ntdll!ZwCallbackReturn

33:00000000771B98D0 mov R10, RCX
......................................mov eax, 2
......................................syscall
......................................ret

If my target has a dialog box open with an OK button already activate but frozen, when I activate 'sysenter', the target executes to completion.

It would not do that in softice. I would have been able to trace right into the system call and through it, sometimes back into user mode code.

Is this a limitation of wdbg? Or is there a way to influence wdbg to trace into the system call? If that problem cannot be overcome, it's not much use to me as a ring 0 debugger. As youknow, there are many times that calls are made into the system and the system calls back into U-mode. That's what I expected to happen in this case but the debugger seems to have lost control and allowed the target to run to completion.

[Kayaker]

Couple random ideas.
Depending on what you're trying to do, you might have a look at nt!KeUserModeCallback / ntdll!KiUserCallbackDispatcher, see if you can get an address of the callback and any kernel buffer pointer.
The PEB might help.
No point in trying to trace into syscalls directly.

[WaxfordSqueers]

Depending on what you're trying to do

Thanks k. I'll check out what you suggest.

What I am trying to do ultimately is find where the OK button leads. I am trying to load a driver and I am watching how Windoze processes the load. I would actually like to set a conditional break where I could check the left button click which is 0x201.

I have several dialog windows open related to Add Hardware in Device Manager. The code I am stepping through is related to those windows. The call into the system is likely related to win32k.sys since it is the system side that deals with graphics.

Normally, I would not care about system calls but on several occasions I have seen a call to the system, call back into a user program or a user system library before returning.

With sice I would often jump over a syscall and find there was something vital in the sys call where I had to trace through system code to the app on which I was working.

That's twice now that I have hit a system callback and had windbg lose control of the tracing process. It should do its business and return, if it is not going to allow tracing through sys code.

[WaxfordSqueers]

I have been reading in-depth stuff about reversing and the Windows kernel-user systems. Part review, part new. I had one of those Homer Simpson Doh!!! moments while reading on the syscall command.

Why not set a bp on the address of the ret command after the syscall?

Doh!!! Don't have time right now but I am interested to see if something happens inside the routine called by syscall or whether the OK dialog box will still be there if it breaks immediately after the syscall.

I got so strung out on what I used to do with softice and where I could set a bp to stop the app going to completion that the totally obvious solution was overlooked.

Meantime, during my reading, I covered some theoretical ground related to your last post about callbacks. Got some ideas on how to place a bp, if required, to investigate further.

Besides, I am rusty as all git out.

+Ork will be smiling at my doh!!! gaffe since he emphasized looking for the obvious.

[WaxfordSqueers]

ps. I have noticed that many people have viewed this thread yet no one but kayaker and blabberer has commented. Please don't feel shy about hyjacking the thread, every comment is welcome. I would like to hear from some of the old RCE crew if for nothing more than to say hello.

Covered something on canonical addressing. I have noticed on occasion that when I try to set a bp in windbg, it gets entered as 0xfffff7fe'xxxxxxxx rather than 0x000007fe'xxxxxxxx. In the former case, the bp is not applied in the right place.

From what I understand, the 64 bit canonical address must have all the same values before the 64 bit msb address, otherwise it changes things. If I have an address listed as 0x0000007fe'xxxxxxxx it can be sub-divided as 0x0000-07fe'xxxxxxxx. The 07fe part of the msb side is an actual 4 byte address. Somehow, wdbg is interpreting it as f7fe and adding ffff in front of it.

[WaxfordSqueers]

Kayaker...wasted an inordinate amount of time on a wild goose (Canadian variety) chase. The OK button issue is a non-entity. It leads to a search for the 'Have Disk' part of the 'Add Hardware' to the required INF file. Once that has been located and OK is hit a new screen appears stating something like 'To start installing your new hardware, hit next'.

I should have been starting from that Next button. That's where the actual driver installation begins. Doh!!!

I had been searching for that string in associated mui files with no luck until I noticed there are two versions of hdwwiz, the add hardware wizard. There is one with an exe extension and one with a cpl extension. The mui for the cpl extension has the string at ordinal 1056 (0x420). I have found that in the Window procedure in IDA @ 0BE03DF0 but they are just putting the dialog box together at that point.

I am trying to recall, but once ShowWindow is executed, the dialog box window with the Next button should appear and wait for input. I don't know if the code below Show Window is related.

I'd really like to find a bp after the Next button to bp on. I have seen reference to:
_imp_SetupDiRegisterDeviceInfo@24 a bit below but have no has time to pursue it.

[blabberer]

Kayaker...don't know if you have the answer for this or if blabberer might.

the dis is from w7 32 but concepts are same (w10 32/64 whatever)

the instruction syscall / sysenter / int 2e / int2b etc are executed from usermode
but the actual work is done in kernel mode

so you may need to wait on the other side with proper breakpoints to catch the action

your fndword

kd> x user32!*fndword*
761301a6          USER32!__fnDWORDOPTINLPMSG (<no parameter info>)
76114f59          USER32!__fnDWORD (<no parameter info>)
kd> uf /c USER32!__fnDWORD
USER32!__fnDWORD (76114f59)
  USER32!__fnDWORD+0x21 (76114f7a):
    unresolvable call: call    dword ptr [eax+14h]
  USER32!__fnDWORD+0x2f (76114f88):
    call to USER32!XyCallbackReturn (76116214)
kd> uf /c USER32!XyCallbackReturn
USER32!XyCallbackReturn (76116214)
    no calls found
kd> uf USER32!XyCallbackReturn
USER32!XyCallbackReturn:
76116214 8b442404        mov     eax,dword ptr [esp+4]
76116218 cd2b            int     2Bh
7611621a c20400          ret     4
kd> $$ it calls an interrupt int 2b
kd> lets see whats in the idt of 2b
    ^ Syntax error in 'lets see whats in the idt of 2b'
kd> !idt 2b

Dumping IDT: 80b95400

552bb9f90000002b:	82e52e90 nt!KiCallbackReturn

kd> $$ so a proper bp /p $proc nt!KiCallbackReturn should get you the action

nt!Kicallbackreturn calls nt!NtCallbackReturn

kd> uf /c nt!KiCallbackReturn
Flow analysis was incomplete, some code may be missing
nt!KiCallbackReturn (82e52e90)
  nt!KiSystemServicePostCall+0x8 (82e528ce):
    call to hal!KeGetCurrentIrql (8322d6ee)
  nt!KiServiceExit+0x1c (82e52938):
    call to nt!KiCopyCounters (82ef80e7)
  nt!KiServiceExit+0x52 (82e5296e):
    call to hal!KfRaiseIrql (8322d844)
  nt!KiServiceExit+0x5f (82e5297b):
    call to nt!KiDeliverApc (82ec5975)
  nt!KiServiceExit+0x65 (82e52981):
    call to hal!KfLowerIrql (8322db48)
  nt!KiServiceExit2+0x159 (82e52c24):
    call to nt!KeBugCheck2 (82ef41c3)
  nt!KiServiceExit2+0x173 (82e52c3e):
    call to nt!KeBugCheck2 (82ef41c3)
  nt!KiServiceExit2+0x188 (82e52c53):
    call to nt!PerfInfoLogSysCallExit (82f26d6d)
  nt!KiCallbackReturn+0x88 (82e52f18):
    call to nt!NtCallbackReturn (82e93f60)


kd> uf /c /D 0x82e93f60
nt!NtCallbackReturn (82e93f60)
  nt!NtCallbackReturn+0x47 (82e93fa7):
    call to nt!KxTransferNpxState (82e93c9c)
  nt!NtCallbackReturn+0xa9 (82e94009):
    call to nt!MmDeleteKernelStack (82eab569)