USB drivers for Win 7 on 8th generation Intel chipset

[blabberer]

With Windbg setup on either computer, each one indicates a connection to COM2 but both freeze, allowing no input, while displaying something like 'waiting to reconnect'.

what do you mean by this ?

you do not think that windbg on host will be talking to windbg in guest(target) ? do you ??


it is one way traffic the guest talks to the windbg running in host about all the events that happen in the guest(target) machine

the windbg in host listens and breaks when appropriate for the human on the host to interpret and handle the event

stop take a breath throw away all the wires and create a vm first get your first break take few baby steps in and out of the code
force forget sice it is and old extinct dinosaur get your feet wet first no point talking 10 things and not doing even one

[WaxfordSqueers]

what do you mean by this ?

you do not think that windbg on host will be talking to windbg in guest(target) ? do you ??

I have read and researched till I am blue in the face and there are no answers as to why both the host and the guest just sit there displaying the message 'waiting to restart'. While those messages are there no entry is possible on either window.

stop take a breath throw away all the wires and create a vm first get your first break take few baby steps in and out of the code
force forget sice it is and old extinct dinosaur get your feet wet first no point talking 10 things and not doing even one

I was hoping to learn by applying Windbg to a real-time project. I have one and I am currently trying to set it up to run on a serial connection. With a VM, I can't very well debug a driver in Windows while it is running on a VM. In fact, that why I want to run a remote session using a serial connection, so I can watch a driver being installed and started. I want to see why it's not starting.

To accomplish that, I need to understand the basics of USB drivers and the USB driver stack, hence the 10 different things at once. I am gaining ground. My initial concern was that W7 had something lacking that could not be overcome. Remember, my problem is getting USB running with W7 on a newer generation motherboard. No one has done it yet with the B360 Intel chipset as far as I know.

Thus far, I have learned that the Windows kernel communicates with USB devices through various levels of drivers. The hub driver is connected right to the hardware and detects it when it is inserted. It queries the device for it's Vendor ID and Hardware ID, in conjunction with the USB Host Controller Driver that sits right above it on the USB stack, then advises the kernel of the new device.

The kernel then instructs the hub to power the device and send it the device info so the kernel can enumerate it via the controller and the hub. I am getting no power to the mobo USB ports under W7 so the hub is not being turned on. In fact, it's currently not loaded. I have seen the USB Host Controller loaded but not turned on. That suggests to me the driver above it is not communicating with the Host Controller or the drivers have code that is not synchronized because calls to certain drivers are reaching the wrong code.

There is a system level driver sitting between the kernel and the USB host controller that may be the problem. I can't get W7 to load any of its USB drivers, even for USB 2 devices.

With the new USB3 controllers, USB 2 and 3 run in parallel but why are all the USB 2 drivers not showing up in Device Manager? They are loaded but not showing up. USBD.SYS is loaded and it's a system level driver that interfaces the kernel to the other USB drivers.

Do you think I can examine all that using a VM? I am not being facetious, I am asking a straight question.

Windows 10 runs USB 3 on my mobo's chipset no problem and Intel released driver in 2018 that allowed W7 to run USB 3. My chipset is a 300-series and the release allowed an earlier revision of my 300-series chipset to run. That suggests to me that it's not W7 causing the problem.

Of course, I read a lot of negative comment about why someone would want to run W7 when it's over 10 years old. One good reason...Windows 10. It's an over-bloated spying device that is so laden down with garbage that it's a surprise it even runs. Have you opened task manager and taken a look at the bloatware processes running? It's astounding.

Last time I tried tracing at the kernel level, I kept running into VM code. Also, after spending hours trying to learn the basic Windbg functions, I got nowhere fast. I learned softice by applying it to actual problems, finding ways to deal with peculiarities in softice. One of the hardest parts was actually setting it up to run properly, as I am currently doing with Windbg.

I realize softice is now severely limited but it's no dinosaur. It's still a very powerful debugger for 32 bit apps if they can be run in an XP environment. I used it very recently and very successfully in a VM. I would like to see it ported to a win7 environment with 64-bit capabilities but I realize that's highly unlikely, so I am making an attempt to move on.

[WaxfordSqueers]

ps...blabberer, what does Kdsrv do?

[blabberer]

I can't very well debug a driver in Windows while it is running on a VM

i do not understand the reservation here can you explain why you cannot ??

here is a sample session breaking on usbuhci.sys loading and stepping right through DriverEntry

i broke on usbuhci.sys using sxe ld:usuhci.sys

this breaks when the system maps the driver

once broken here you can set a bp on this driver's DriverEntry() function and continue

i have broken here because of sxe ld:usbuhci.sys

kd> .lastevent
Last event: Load module usbuhci.sys at 887d0000
  debugger time: Sun Mar 10 23:12:36.333 2019

stack trace when broken

kd> kb
 # ChildEBP RetAddr  Args to Child              
00 8bb476fc 818a4308 8bb47714 8bb476ec ffffffff nt!DbgLoadImageSymbols+0x41
01 8bb4771c 81ad0815 0000004a 8d4c11a8 00000000 nt!DbgLoadImageSymbolsUnicode+0x24
02 8bb47758 81acc296 8bb478f8 8bb477c8 8bb477ac nt!MiDriverLoadSucceeded+0x13b
03 8bb47840 81a60809 00000000 00000000 8bb478e4 nt!MmLoadSystemImageEx+0x39c
04 8bb47858 81a63744 8bb478f8 00000000 00000000 nt!MmLoadSystemImage+0x25
05 8bb47958 81b34a32 00000000 8bb47988 00000005 nt!IopLoadDriver+0x1f6
06 8bb4799c 81a6785b 00000003 00000000 00000002 nt!PipCallDriverAddDeviceQueryRoutine+0x16c
07 8bb479c8 81a68739 00000005 8c1e1f08 800000ac nt!PnpCallDriverQueryServiceHelper+0x6f
08 8bb47ab0 81a67d0c 00000000 8d4aa378 8d4aa378 nt!PipCallDriverAddDevice+0x293
09 8bb47c9c 81b7c522 8bb47cc0 00000000 00000000 nt!PipProcessDevNodeTree+0x13c
0a 8bb47cc8 818da9b7 81a06320 8c1b1040 818da6ce nt!PiProcessStartSystemDevices+0x44
0b 8bb47d28 8187b1bc 00000000 00000000 8c1b1040 nt!PnpDeviceActionWorker+0x2e9
0c 8bb47d78 818a8516 81a2f1e0 c46e4180 00000000 nt!ExpWorkerThread+0xc0
0d 8bb47db0 81923ad5 8187b0fc 81a2f1e0 00000000 nt!PspSystemThreadStartup+0x4a
0e 8bb47dbc 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x15

the driver that is being loaded

kd> ds /c 100 8bb47714
8d4ca680  "\Windows\System32\drivers\usbuhci.sys"

setting an breakpoint on DriverEntry and Continuing

kd> bp usbuhci!DriverEntry
kd> g

our breakpoint got hit

Breakpoint 0 hit
usbuhci!DriverEntry:
887d1000 8bff            mov     edi,edi

stack trace on this breakpoint

kd> kb
 # ChildEBP RetAddr  Args to Child              
00 8bb47860 887d8015 8bb47958 81a639a3 8d4d1510 usbuhci!DriverEntry
01 8bb47868 81a639a3 8d4d1510 8d4d5000 8bb47a3c usbuhci!GsDriverEntry+0x15
02 8bb47958 81b34a32 00000000 8bb47988 00000005 nt!IopLoadDriver+0x455
03 8bb4799c 81a6785b 00000003 00000000 00000002 nt!PipCallDriverAddDeviceQueryRoutine+0x16c
04 8bb479c8 81a68739 00000005 8c1e1f08 800000ac nt!PnpCallDriverQueryServiceHelper+0x6f
05 8bb47ab0 81a67d0c 00000000 8d4aa378 8d4aa378 nt!PipCallDriverAddDevice+0x293
06 8bb47c9c 81b7c522 8bb47cc0 00000000 00000000 nt!PipProcessDevNodeTree+0x13c
07 8bb47cc8 818da9b7 81a06320 8c1b1040 818da6ce nt!PiProcessStartSystemDevices+0x44
08 8bb47d28 8187b1bc 00000000 00000000 8c1b1040 nt!PnpDeviceActionWorker+0x2e9
09 8bb47d78 818a8516 81a2f1e0 c46e4180 00000000 nt!ExpWorkerThread+0xc0
0a 8bb47db0 81923ad5 8187b0fc 81a2f1e0 00000000 nt!PspSystemThreadStartup+0x4a
0b 8bb47dbc 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x15

the disassembly of DriverEntry For usbuhci.sys

target is (win 10 15063 x86 32 bit vm running in some old 32 bit (now discontinued vmware player )
host is running 32 bit win 7 x86 15 year old celeron processor

kd> uf .
usbuhci!DriverEntry:
887d1000 8bff            mov     edi,edi
887d1002 55              push    ebp
887d1003 8bec            mov     ebp,esp
887d1005 81ec18010000    sub     esp,118h
887d100b a100707d88      mov     eax,dword ptr [usbuhci!__security_cookie (887d7000)]
887d1010 33c5            xor     eax,ebp
887d1012 8945fc          mov     dword ptr [ebp-4],eax
887d1015 56              push    esi
887d1016 57              push    edi
887d1017 8d85e8feffff    lea     eax,[ebp-118h]
887d101d c785e8feffff14010000 mov dword ptr [ebp-118h],114h
887d1027 50              push    eax
887d1028 8bf2            mov     esi,edx
887d102a 8bf9            mov     edi,ecx
887d102c ff15c4607d88    call    dword ptr [usbuhci!_imp__RtlGetVersion (887d60c4)]
887d1032 83255c717d8800  and     dword ptr [usbuhci!RegistrationPacket+0x13c (887d715c)],0
887d1039 56              push    esi
887d103a 6820707d88      push    offset usbuhci!RegistrationPacket (887d7020)
887d103f 68f4010000      push    1F4h
887d1044 c70530707d8898010000 mov dword ptr [usbuhci!RegistrationPacket+0x10 (887d7030)],198h
887d104e c70534707d8898000000 mov dword ptr [usbuhci!RegistrationPacket+0x14 (887d7034)],98h
887d1058 c70538707d8824000000 mov dword ptr [usbuhci!RegistrationPacket+0x18 (887d7038)],24h
887d1062 c70544707d88c0220000 mov dword ptr [usbuhci!RegistrationPacket+0x24 (887d7044)],22C0h
887d106c c70544727d8816187d88 mov dword ptr [usbuhci!RegistrationPacket+0x224 (887d7244)],offset usbuhci!UhciPreStartController (887d1816)
887d1076 c70558707d881e187d88 mov dword ptr [usbuhci!RegistrationPacket+0x38 (887d7058)],offset usbuhci!UhciStartController (887d181e)
887d1080 c7055c707d88f4167d88 mov dword ptr [usbuhci!RegistrationPacket+0x3c (887d705c)],offset usbuhci!UhciStopController (887d16f4)
887d108a c70594707d88285a7d88 mov dword ptr [usbuhci!RegistrationPacket+0x74 (887d7094)],offset usbuhci!UhciEnableInterrupts (887d5a28)
887d1094 c70598707d886e597d88 mov dword ptr [usbuhci!RegistrationPacket+0x78 (887d7098)],offset usbuhci!UhciDisableInterrupts (887d596e)
887d109e c70568707d88a4567d88 mov dword ptr [usbuhci!RegistrationPacket+0x48 (887d7068)],offset usbuhci!UhciInterruptService (887d56a4)
887d10a8 c7056c707d8868597d88 mov dword ptr [usbuhci!RegistrationPacket+0x4c (887d706c)],offset usbuhci!UhciInterruptDpc (887d5968)
887d10b2 c70560707d88222a7d88 mov dword ptr [usbuhci!RegistrationPacket+0x40 (887d7060)],offset usbuhci!UhciSuspendController (887d2a22)
887d10bc c70564707d88a02b7d88 mov dword ptr [usbuhci!RegistrationPacket+0x44 (887d7064)],offset usbuhci!UhciResumeController (887d2ba0)
887d10c6 c705f0707d88aa5a7d88 mov dword ptr [usbuhci!RegistrationPacket+0xd0 (887d70f0)],offset usbuhci!UhciRHDisableIrq (887d5aaa)
887d10d0 c705f4707d88aa5a7d88 mov dword ptr [usbuhci!RegistrationPacket+0xd4 (887d70f4)],offset usbuhci!UhciRHDisableIrq (887d5aaa)
887d10da c705b0707d88a82e7d88 mov dword ptr [usbuhci!RegistrationPacket+0x90 (887d70b0)],offset usbuhci!UhciRHGetRootHubData (887d2ea8)
887d10e4 c705b4707d88022f7d88 mov dword ptr [usbuhci!RegistrationPacket+0x94 (887d70b4)],offset usbuhci!UhciRHGetStatus (887d2f02)
887d10ee c705bc707d88162f7d88 mov dword ptr [usbuhci!RegistrationPacket+0x9c (887d70bc)],offset usbuhci!UhciRHGetHubStatus (887d2f16)
887d10f8 c705b8707d88ba2f7d88 mov dword ptr [usbuhci!RegistrationPacket+0x98 (887d70b8)],offset usbuhci!UhciRHGetPortStatus (887d2fba)
887d1102 c705c0707d8852347d88 mov dword ptr [usbuhci!RegistrationPacket+0xa0 (887d70c0)],offset usbuhci!UhciRHSetFeaturePortReset (887d3452)
887d110c c705c8707d889e2f7d88 mov dword ptr [usbuhci!RegistrationPacket+0xa8 (887d70c8)],offset usbuhci!UhciRHSetFeaturePortEnable (887d2f9e)
887d1116 c705c4707d88b42f7d88 mov dword ptr [usbuhci!RegistrationPacket+0xa4 (887d70c4)],offset usbuhci!UhciRHClearFeaturePortPower (887d2fb4)
887d1120 c705cc707d88ee357d88 mov dword ptr [usbuhci!RegistrationPacket+0xac (887d70cc)],offset usbuhci!UhciRHSetFeaturePortSuspend (887d35ee)
887d112a c705d8707d8830377d88 mov dword ptr [usbuhci!RegistrationPacket+0xb8 (887d70d8)],offset usbuhci!UhciRHClearFeaturePortSuspend (887d3730)
887d1134 c705d0707d88882f7d88 mov dword ptr [usbuhci!RegistrationPacket+0xb0 (887d70d0)],offset usbuhci!UhciRHClearFeaturePortEnable (887d2f88)
887d113e c705d4707d88b42f7d88 mov dword ptr [usbuhci!RegistrationPacket+0xb4 (887d70d4)],offset usbuhci!UhciRHClearFeaturePortPower (887d2fb4)
887d1148 c705e0707d8832387d88 mov dword ptr [usbuhci!RegistrationPacket+0xc0 (887d70e0)],offset usbuhci!UhciRHClearFeaturePortConnectChange (887d3832)
887d1152 c705e4707d88f2387d88 mov dword ptr [usbuhci!RegistrationPacket+0xc4 (887d70e4)],offset usbuhci!UhciRHClearFeaturePortResetChange (887d38f2)
887d115c c705dc707d889c387d88 mov dword ptr [usbuhci!RegistrationPacket+0xbc (887d70dc)],offset usbuhci!UhciRHClearFeaturePortEnableChange (887d389c)
887d1166 c705e8707d880e397d88 mov dword ptr [usbuhci!RegistrationPacket+0xc8 (887d70e8)],offset usbuhci!UhciRHClearFeaturePortSuspendChange (887d390e)
887d1170 c705ec707d882a397d88 mov dword ptr [usbuhci!RegistrationPacket+0xcc (887d70ec)],offset usbuhci!UhciRHClearFeaturePortOvercurrentChange (887d392a)
887d117a c705a8707d8816207d88 mov dword ptr [usbuhci!RegistrationPacket+0x88 (887d70a8)],offset usbuhci!UhciSetEndpointStatus (887d2016)
887d1184 c705a4707d8896207d88 mov dword ptr [usbuhci!RegistrationPacket+0x84 (887d70a4)],offset usbuhci!UhciGetEndpointStatus (887d2096)
887d118e c705a0707d883e247d88 mov dword ptr [usbuhci!RegistrationPacket+0x80 (887d70a0)],offset usbuhci!UhciSetEndpointDataToggle (887d243e)
887d1198 c70548707d88161a7d88 mov dword ptr [usbuhci!RegistrationPacket+0x28 (887d7048)],offset usbuhci!UhciOpenEndpoint (887d1a16)
887d11a2 c7054c707d88981c7d88 mov dword ptr [usbuhci!RegistrationPacket+0x2c (887d704c)],offset usbuhci!UhciPokeEndpoint (887d1c98)
887d11ac c70550707d88f41d7d88 mov dword ptr [usbuhci!RegistrationPacket+0x30 (887d7050)],offset usbuhci!UhciQueryEndpointRequirements (887d1df4)
887d11b6 c70554707d883e1c7d88 mov dword ptr [usbuhci!RegistrationPacket+0x34 (887d7054)],offset usbuhci!UhciCloseEndpoint (887d1c3e)
887d11c0 c70584707d88ca1e7d88 mov dword ptr [usbuhci!RegistrationPacket+0x64 (887d7084)],offset usbuhci!UhciPollEndpoint (887d1eca)
887d11ca c70580707d8804217d88 mov dword ptr [usbuhci!RegistrationPacket+0x60 (887d7080)],offset usbuhci!UhciSetEndpointState (887d2104)
887d11d4 c7057c707d8870217d88 mov dword ptr [usbuhci!RegistrationPacket+0x5c (887d707c)],offset usbuhci!UhciGetEndpointState (887d2170)
887d11de c7058c707d88c2217d88 mov dword ptr [usbuhci!RegistrationPacket+0x6c (887d708c)],offset usbuhci!UhciGet32BitFrameNumber (887d21c2)
887d11e8 c7059c707d8850227d88 mov dword ptr [usbuhci!RegistrationPacket+0x7c (887d709c)],offset usbuhci!UhciPollController (887d2250)
887d11f2 c70588707d88602e7d88 mov dword ptr [usbuhci!RegistrationPacket+0x68 (887d7088)],offset usbuhci!UhciCheckController (887d2e60)
887d11fc c70590707d88ae5a7d88 mov dword ptr [usbuhci!RegistrationPacket+0x70 (887d7090)],offset usbuhci!UhciInterruptNextSOF (887d5aae)
887d1206 c70570707d88d0227d88 mov dword ptr [usbuhci!RegistrationPacket+0x50 (887d7070)],offset usbuhci!UhciSubmitTransfer (887d22d0)
887d1210 c70574707d88584d7d88 mov dword ptr [usbuhci!RegistrationPacket+0x54 (887d7074)],offset usbuhci!UhciIsochTransfer (887d4d58)
887d121a c70578707d8864237d88 mov dword ptr [usbuhci!RegistrationPacket+0x58 (887d7078)],offset usbuhci!UhciAbortTransfer (887d2364)
887d1224 c705f8707d889e247d88 mov dword ptr [usbuhci!RegistrationPacket+0xd8 (887d70f8)],offset usbuhci!UhciStartSendOnePacket (887d249e)
887d122e c705fc707d883c277d88 mov dword ptr [usbuhci!RegistrationPacket+0xdc (887d70fc)],offset usbuhci!UhciEndSendOnePacket (887d273c)
887d1238 c70500717d8808247d88 mov dword ptr [usbuhci!RegistrationPacket+0xe0 (887d7100)],offset usbuhci!UhciPassThru (887d2408)
887d1242 c70548717d88f2597d88 mov dword ptr [usbuhci!RegistrationPacket+0x128 (887d7148)],offset usbuhci!UhciFlushInterrupts (887d59f2)
887d124c c70598717d880e587d88 mov dword ptr [usbuhci!RegistrationPacket+0x178 (887d7198)],offset usbuhci!UhciInterruptDpcEx (887d580e)
887d1256 c705f8717d88c6167d88 mov dword ptr [usbuhci!RegistrationPacket+0x1d8 (887d71f8)],offset usbuhci!UhciHaltController (887d16c6)
887d1260 c705ec717d88541c7d88 mov dword ptr [usbuhci!RegistrationPacket+0x1cc (887d71ec)],offset usbuhci!UhciDbgFreeEndpointEndpoint (887d1c54)
887d126a c70524707d88c3020000 mov dword ptr [usbuhci!RegistrationPacket+0x4 (887d7024)],2C3h
887d1274 c70520707d8802000000 mov dword ptr [usbuhci!RegistrationPacket (887d7020)],2
887d127e c70528707d88e02e0000 mov dword ptr [usbuhci!RegistrationPacket+0x8 (887d7028)],2EE0h
887d1288 83673400        and     dword ptr [edi+34h],0
887d128c 57              push    edi
887d128d ff15b8607d88    call    dword ptr [usbuhci!_imp__USBPORT_RegisterUSBPortDriver (887d60b8)]
887d1293 8b4dfc          mov     ecx,dword ptr [ebp-4]
887d1296 5f              pop     edi
887d1297 33cd            xor     ecx,ebp
887d1299 5e              pop     esi
887d129a e8f7480000      call    usbuhci!__security_check_cookie (887d5b96)
887d129f 8be5            mov     esp,ebp
887d12a1 5d              pop     ebp
887d12a2 c3              ret

kdsrv is a server application you run that on target


you can connect to it using any debugger (windbg , kd , cdb , from a client machine )

[WaxfordSqueers]

i do not understand the reservation here can you explain why you cannot ??

First of all I want to express my appreciation for all the work you do in order to give these examples. It's really appreciated.

The reason I cannot is because I am trying to load USB 3 drivers for W7 on an 8th generation 300-series Intel chipset (B360) and neither Microsoft nor Intel have provided W7 drivers for my particular USB Vendor/Device revision. If I try to load the required drivers in a VM, they are not being loaded using my particular chipset. And I doubt that a current VM can virtualize my particular chipset.

It might be interesting to see what would happen if I tried to force a USB 3 driver install on W7 VM to see where the problem arises.

Here's a link to drivers from Intel for W7 on my generation chipset. See if you can load them on a normal W7 installation. I don't think you can but I am interested in what goes wrong during the installation. Is it an address conflict due to a call to code that has changed?

If you use the Intel setup.exe it will produce an error message claiming something is wrong. If you use the Device Manager new hardware Wizard you can point it at the INF files under drivers.

https://downloadcenter.intel.com/download/22824/Intel-USB-3-0-eXtensible-Host-Controller-Driver-for-Intel-8-9-100-Series-and-Intel-C220-C610-Chipset-Family?product=65855

usbuhci.sys is a miniport driver associated with USB 2. So, if you have a fully functioning USB 2 system working, there should be no problem loading drivers. However, I have no USB operating natively in W7 at the moment on my B360 chipset mobo. There are no W7 native drivers showing up in Device Manager even for USB 2 drivers. The moment I plugged my W7 installation into the new mobo, all USB drivers disappeared.

I do have a VIA USB 3 peripheral card running on W7 but it uses it's own USB chipset and drivers. Those drivers show up in DM.

Intel did supply drivers for an earlier revision of the 300-series chipset but for some reason the drivers fail to load, giving an error 10. Even if I could load the USBXHCI.SYS USB Host Controller driver using your method, what good does it do me if the driver is not speaking to to the kernel or to the hub below it?

Seems to me, and I stand to be corrected, I have to approach this through the loading process from Device Manager. If you have the time and interest could you open Device Manager in a W7 installation, select a driver category, then open the 'Action' menu. Select "Add Legacy Hardware'. See if you can trap the process used to load drivers from the Wizard that opens.

You mentioned doing 10 different things. I could quite easily make it 20, there are so many different approaches here.

I have no idea what I'm dealing with. Did Intel release a revision with hardware removed? Don't think so because the board works fine with W10 drivers on my current chipset revision. It would likely work fine with W8 drivers.

My task is to discover what it is about the relationship between my current B360 chipset and the USB 3 drivers that will not allow the drivers to load. If there are drivers that allow W10 to load USB 3 drivers and work fine on the B360, what is it with W7? Till very recently, Intel released the W7 drivers at the link above that work on the 300-series chipset and my B360 is a 300-series chipset.

[Kayaker]

If you use the Intel setup.exe it will produce an error message claiming something is wrong.

You mean this error message?



The string is from the Lang/en-US/Setup.exe.mui resource-only file. The name indicates the message is generated from the main 32-bit Setup.exe file itself. While I haven't tried it, breaking at (MessageBoxIndirectW) would seem like the first step? Maybe you can interpret what feature the code is looking for.


Nice stuff Blabbs. On a side note, have you ever found a good replacement for OSR IrpTracker?

There's this, but the driver is not digitally signed:
https://github.com/MartinDrab/IRPMon/releases

[WaxfordSqueers]

open a windbg instance in physical machine which is running the vm file -> kernel debug -> com -> check pipe , check reconnect , leaves resets at 0 , leave baudrate at 115200 provide the pipe that you set up \\.\pipe\dbgpipe

hit ctrl+break or alt+delete a few times and you should be ready to go

I will get to the VM but I wanted to establish a serial connection just for the heck of it. I am now good to go, had some issues in the null modem cable.

I used Putty, a free app that can check serial ports, and I can now send text messages via com2 at 115200 baud rate. So there is a com 2 connection and I am wired in the cable exactly as Msoft suggested.

Therefore, I should, in theory, have the same situation you describe above, except I have a direct serial connection.

Maybe I am doing this wrong. I opened Windbg in the host and selected kernel debug. Set up the serial port as you describe. Opened another Windbg session in the guest but it's not clear whether I have to open a kernel debug session on that end, or maybe use 'connect to a remote session'.

I tried kernel debug but both windows sit there claiming 'debuggee not connected' and 'waiting to reconnect'. Both machines indicate they have opened \\.\com2.

Sorry for the dumb questions.

[WaxfordSqueers]

You mean this error message?



The string is from the Lang/en-US/Setup.exe.mui resource-only file. The name indicates the message is generated from the main 32-bit Setup.exe file itself. While I haven't tried it, breaking at (MessageBoxIndirectW) would seem like the first step? Maybe you can interpret what feature the code is looking for.

Yep, that's the message. It's not clear what it means since my chipset exceeds the minimum requirements. I think when those drivers were issued, the B360 chipset was not yet released.

I have already traced quite a ways into that setup.exe using Olly 2 and saw a reference to not loading drivers beyond the Skylake chipset version, which is a bit older than mine. I am going to try it again later. Unfortunately Olly 2 choked on it along the way.

If you have a moment, try loading it in sice. It's a 32 bit app but it would not break on _baseprocessaddress. I noted a TLS entry in IDA and I had wondered if something is diverting it during the loading process.

As a disclaimer, I have absolutely no intention of reverse engineering the app, I am only looking for information as to why the drivers cannot be loaded. I believe Matt Pietrek called it 'spelunking'. Maybe we should contact Matt and see if he'll revive sice.

[blabberer]

that was what i was asking two threads earlier

you are not supposed to open two windbg and expect both of them to talk to each other

you are supposed to boot into debugmode and windbg that is listening on the host will connect to the boot

in target open cmd.exe

in the command prompt use bcdedit to create another boot menu

so when you press the power button on

you get two bootable options
one plain
one debug enabled

and a 30 seconds timeout to choose one of the option

here you choose the second debug enabled boot and windbg will come to life in the host

[WaxfordSqueers]

@blabberer....reading more on this.

Seems I first have to declare the debugging machine as a server using the .server command. Then I have to go on the client machine and open a remote session using
comort=COMPort,baud=BaudRate,channel=COMChannel[,password=Password]

It tried but it's getting late and I am bleary eyed.

I opened Notepad in my desktop and got to a prompt. I entered .server and got a message specifying the format.

I entered '.server npipe: Pipe=Com2' and it opened a server connection using my user name on the desktop. I got:

0: <debugger> -remote npipe: Pipe=Com2, Server=<my user name>

Maybe a pipe is not what I want.

I have been unable as yet to connect the laptop, even though I know COM2 is working fine at 115200 baud.

I have just as much trouble trying to open a VM connection.

[WaxfordSqueers]

you are supposed to boot into debugmode and windbg that is listening on the host will connect to the boot

I already have the desktop in debug mode. If I set Windbg into kernel debug mode and boot the desktop into debug mode, nothing happens. It indicates it has opened //./com2 but is waiting to reconnect.

It's too late I'll work on this tomorrow.

Thanks for your patience and time.

[Kayaker]

Unless you are bound and determined to debug through a COM port for some reason, you might want to start with a basic VM setup, as Blabberer suggested, and see how far along you get with driver debugging or the setup file, if that's what your goal is. Maybe revisit the cable connection later.

FWIW, I just set up a Win10 host -> Win7x64 guest VM using VirtualKD and followed along with Blabs usbuhci.sys debugging example. Took all of oh 5 minutes, no fuss no muss.

I think I understand why you want to debug through a serial connection, Win7 booting with your MB under a VM isn't *exactly* the same as Win7 booting with your MB on your computer, maybe especially when it comes to USB connections. VirtualKD might even solve that problem, where the host is your laptop and your computer is the guest. Since the whole purpose of VirtualKD is to make it easier (and faster communication) for remote debugging, it really might be worth trying it.

[WaxfordSqueers]

Unless you are bound and determined to debug through a COM port for some reason, you might want to start with a basic VM setup, as Blabberer suggested, and see how far along you get with driver debugging or the setup file, if that's what your goal is. Maybe revisit the cable connection later.

I am not bound to any approach in particular and I am heeding the advice of Blabbs and yourself closely. I regard you and Blabbs highly, regarding both of you as being among the elite in reversing, especially at a normal level where your interests are more academic.

My current interest in the com port has more to do with my hardware background. I have expertise in that area and I 'should' be able to get this connection going. It interests me as to why it was not going before and it turned out to be a bad assumption about null modem cables.

***this can be skipped...technical diarrhea****

FYI, when you look at a straight-through, typical female to female serial cable it does not matter how the internal wires are coloured as long as they are run from 'equivalent' pins to equivalent pins. Once you cut that cable to route the conductors in different ways, to make a null modem cable, you have to be very careful with regard to the D-shell orientation.

When D-shells plug into each other they do as as a mirror image of each other. If you pull them apart and rotate them through 180 degrees, and view them, they form a mirror image with the short end of the D adjacent and the longer ends on opposite sides. If you now locate pin 1 on the longer pin side, which should be indicated on the terminal connector or in it's literature, pin 1 on the longer female connector is directly opposite it on the outside.

If you don't pay close attention to that alignment, right along the chain, when you have the cable unplugged, you can quite easily get pins 1 and 5 reversed by having the plug upside down. To make matters worse, the adapter connecting to the mobo serial port, which bring it out to the back panel, is a ribbon cable.

On the mobo end the connector is numbered across the connector so that odd numbered pin counts are 1,3,5,7,9 along one side and 2,4,6,8 along the other. However, the D-shell pinout is number 1,2,3,4,5 along the wide side of the D and 6,7,8,9 along the short side with the 6 opposite and between the 1,2 pins.

When you transition from a keyed mobo connector, through a flat ribbon cable, through two D-shell connectors, through a serial cable, through another two D-shells and into a USB to serial adapter D-shell, the mind can become rather boggled trying to keep everything aligned while one makes a drawing.

When you cut the cable, there are 9 different coloured conductors inside but you can't see where they connect to the connector because the connectors are molded plastic. So you have to ring them out with an ohmmeter. Some of the conductors in the cable follow the resistor colour code as R,O,Y,G,B,V,S (red orange, yellow, green, blue, violet, slate).

What I forgot is that some manufactures start at black on pin 1 and brown on pin 2, then pin 3 is R, 4 is O, etc.

What threw me was the black, which is normally ground. It was connected to the end pin on the long side of the D and ground in a serial connector is 5, so I presumed black was pin 5. Wrong!!! I was holding the D-shell backwards and that was actually pin 1. Turned out ground was yellow.

See how easy it is to blow up a motherboard? Thankfully, serial does not expose voltages directly to the bus. They are exposed through pull up and pull down arrangements where the serial chip is exposed via resistors of sufficient size to limit the current.

Motherboard normally also implement current limiting in case some idiot, like me, reverses the wrong connections.

*********************

I think I understand why you want to debug through a serial connection, Win7 booting with your MB under a VM isn't *exactly* the same as Win7 booting with your MB on your computer, maybe especially when it comes to USB connections. VirtualKD might even solve that problem, where the host is your laptop and your computer is the guest. Since the whole purpose of VirtualKD is to make it easier (and faster communication) for remote debugging, it really might be worth trying it.

Thanks for the insight. Blabbs is a good guy and a good teacher and I'm sure he regards me as being somewhat obtuse in this regard. I think his message is quit messing with irrelevant detail and get on a VM so you can learn Windbg. His point is well taken and he'll receive no argument from me.

As I pointed out to him, I have had similar issues setting up a virtual COM port on a VM and I would really like to see this serial configuration work.

You mentioned Wireshark in a previous post and I am going to try that or some other app that will allow me to most definitely verify communications between computers.

Putty is showing a COM2 connection, I can type messages between the Putty terminals on either machine. Telnet complains about port 23 being blocked and that sounds like a Firewall issue.

I will d/l VirtualKD and check it out. Thanks for suggestion.

[WaxfordSqueers]

@ Kayaker @blabberer

I have a serial port monitor on a laptop and Windbg on a desktop. Windbg is open as a kernel debugger and it's sending an IRP_MJ_READ to the laptop via COM2 through a cable. Those are the sets of iiiiis I talked about. They are related to the IRP.

I have been told to reboot the laptop and that the desktop Windbg should detect the reboot in debug mode and perform some kind of action.

Question: If Wdbg is sending out an IRP_MJ_READ it is trying to read something. What the heck can it read? I find that to be utterly confusing. I have tried sending a ctrl-break and an alt-del, plus several other keys. It just sits there with the message:

opened \\.\com2
Waiting to reconnect

It acknowledges being connected to com2 and it is getting an IRP through to the laptop's com2, where it is being monitored by a serial port tool.

I have tried it both ways and verified on both machines using bcdedit that both machines are in debug mode and both on COM2 at 115200 baud.

I have experienced the same problem in VMs, not exactly the same issue, but the failure to connect.

The problem is, I have no idea what to expect on the other end. Blabbs laid it out very simply about hitting ctrl-break or alt-del but there is no response from wdbg.

What the heck is Windbg trying to connect to? If it is coming in through a serial port how would it know what to look for? I could see it with telnet via a network with a telnet client on the other end. I can do it with Putty with a Putty client open in the other machine. But what the heck would wdbg be looking for if it does not have another version of itself open?

Telnet fails due to the utter insanity introduced by msoft re security. It requires users on another computer to be part of the TelnetClient group. Guess what. When you try to add a user on another computer it tells you it can't find that user.

Well, duh!!!! Of course not, I am trying to tell you about it you dumb-ass Wizard. It's as bad as the security in Windows. How many times have I tried to change security permissions on a file or registry key in windoze, as Administrator, only to be told I don't have the level of security required to access the file or key.

Oh, I have a perfect fix for that garbage. I go into the mft and change the permissions at the root. And I mean ROOT. You can do anything you want to permissions in the mft if you know where to find it.

If I get a connection, what am I looking for....a window with a cursor? Or do I get access to Explorer so I can load a file or a DRIVER?

There is very little info on this. Even msoft, who write volumes on it, are seriously terse about what to expect when a connection is established.

The same problem about 'waiting to reconnect' is prevalent on the Net and I have not read a satisfactory solution. It may be related to particular mobos and/or versions of OSs.

[WaxfordSqueers]

@blabberer @kayaker

Spent a lot of time going over what you guys have told me and doing further research.

Thus far, I have confirmed I am getting communication between windbg either way, between my desktop and laptop via a serial cable.

I have begun to notice issue with the symbol server, much of which I have corrected. However, a nagging problem persists. Windbg is completely ignoring the environment variables where I have set _NT_SYMBOL_PATH as:

srv*c:\syms*https://msdl.microsoft.com/download/symbols

Where c:\syms is my symbol store.

If I fire up windbg and load notepad, it will populate my store with ntdll.pdb. After running notepad it populated the store further with deferred pdb files.

When I restart windbg, my symbol path is gone, replace with just srv*. Then wdbg complains about not being able to find symbol files.

It's this sort of crap that I am sure turns people off from using windbg. It's typical Microsoft bs...convoluted, abstracted nonsense that has no logical basis other than to Microsoft weenies.

Furthermore, I cannot find a way to d/l core system files like ntoskrnl, win32, hal, or anything other than ntdll, kernel32, gdi32, and user32.

I have read that my current issue may be related to wdbg being unable to find required symbol files when it watches for the debuggee. [/whine off].