USB drivers for Win 7 on 8th generation Intel chipset

[blabberer]

sorry to be a prick but I will outline things once again ( I understand you like hard wares )

download VMware player (free and x64)
download 90 days evaluation version of windows 10 enterprise (1809)
install VMware (all default settings using NAT for network (apipa range local domain and dhcp for internet no serial crap absolutely none)
install windows 10 inside it
create a shared folder in the host and enable shared folder access in VMware (easy way)
copy kdnet.exe / kdmanifestxxxx.xml to the shared folder
copy both of them from shared folder to desktop of VMware
run kdnet from a command prompt it will say if your nic is ok for kd or not
if it is ok

ping 192.168.xxxx
if you get a response from host ( do ipconfig on host and find what the ip is if there are several ping all of them and note which one responds)

do kdnet 192.168.xxxxx 50000 (this will enable the only bootable partition to be debug enabled and set dbgsettings to net debugging)

it will provide you a key
copy it to foo.txt and dump it in shared folder so that access the key in host

open a command prompt in host

c:\xxxxx\windbg.exe -k netort=50000 , key=yyyyyyyzzzzzzaaaaaa
it will open a windbg with waiting to reconnect

go to target and in the command prompt that you did kdnet
type
shutdown -r -t 0

when the target restarts your windbg that is waiting for connection will connect to the os and you are ready for kernel debugging

once you do this you can take all the cables screwdrivers nuts and bolts and bang them till they connect with hammers

and I reread the question

no kd -kl is NOT KERNEL DEBUGGING
loosely said it creates dump of the current machine and debugs that dump
it is kind of viewing snapshot of the entire system in a debugger
it is ONCE AGAIN NOT KERNEL DEBUGGING

[WaxfordSqueers]

sorry to be a prick but I will outline things once again ( I understand you like hard wares )

Oh, be a prick if you want. I've known you long enough to know your a good guy under it all. I don't blame you, as I said it must be exasperating for you to explain things with a VM and have me persist with the hardware.

Furthermore I remember how you used to carry on about softice, even though Kayaker and I tried to edjumacate you as to the superiority of ice.

I am close to using the VM but this damned hardware should work and I am finding it a major challenge to find out why it does not. I mean, serial ports are dead, stupid simple in the real world and I don't think it's the hardware. I think the problem is Microsoft and their damned permission paranoia.

Why is it no one on the Net understands what's going on? I contacted a guy on a blog who gave me a hint. He told me to try CTL+ALT+D on Windbg and it would give a bit more info, which it did. I actually have Wdbg on the host talking to KD a little bit on the target. I don't think they know they are talking to each other but they are responding to commands like .restart over the serial port.

kd -kl is NOT KERNEL DEBUGGING

I knew that!!! I have been entering KD by itself on the target and it sits there after opening \\.\COM2 and whine's the same as wdbg on the host that it's waiting to reconnect. I have also used KD -t, and KD -k comm:Port=COM2, Baud=115200.

However, while in one of the instances with KD on the target I entered .restart and it sent a message to wdbg on the host. The host was spitting out the 'wait for type 7 packet' and 'timeout' when suddenly the target sent back the message about packet 6 and the host acknowledged it.

It seems to have received a reset.

READ: Wait for type 7 packet
READ: Timeout.
READ: Wait for type 7 packet
READ: Timeout.
READ: Wait for type 7 packet
READ: Timeout.
READ: Wait for type 7 packet
READ: Timeout.
READ: Wait for type 7 packet
      PacketType=6, ByteCount=0, PacketId=0,
READ: Recieved KD_RESET packetThrottle 0x10 write to 0x1
, send KD_RESET ACK packet
READ: Wait for type 7 packet
READ: Timeout.
READ: Wait for type 7 packet
READ: Timeout.
READ: Wait for type 7 packet
READ: Timeout.
READ: Wait for type 7 packet
READ: Timeout.
READ: Wait for type 7 packet

[QUOTE=blabberer;97677]download VMware player (free and x64)
download 90 days evaluation version of windows 10 enterprise (1809)[/CODE]
I already have VMWare Player 15 running on both W7 and W10 on the desktop and W7 on the laptop. I have my own version of W10 from when they were giving it away free.

In fact, I have a copy running on a separate drive but I'm not sure if I could clone it onto a VM disk.

I have already done much of the setup you describe on my real computer and got the key. I'll try it with the VM. I'm not that far away from using the VM.

[WaxfordSqueers]

@blabberer....found a good use for kd -kl

The -kl command line works only when the computer is in debug mode. Makes sense, if you are debugging locally you should be in debug mode.

With kd open under -kl, you can use debugger extensions to examine various aspects of the machine. The extension usb3kd.dll allows you to examine aspects of USB. The extensions are in the winext dir of the address below in x64 directory.

You are probably aware of that already.

I wonder if an extension is available for the serial port?

[WaxfordSqueers]

@blabbs

Question. Is there a way to control the output of the screen to one page at a time in kd?

For example, if I enter !process 0 0 there is so much data scrolling by that by the time it stops I have lost much of the starting procs. I tried adjusting the buffer size for history in the cmd window but no go.

It just occurred to me that powershell might work better.

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

Answering my own question, yes it does. Powershell lists them all.

[blabberer]

-kl switch is applicable to windbg also and it has a much much bigger screen buffer
use windbg -kl with all your windows in full glory

if you dont want to enable debug swich in bcdedit download livekd from sysinternals and use livekd -k pathtowindbg.exe

this will be equivalent to kd -kl but without debug switch in bcdedit

edit

you can start the session with logging enabled -logo
or start logging to a file all you do in an open session with .logopen command

this will dump everything to a file that is if you have a marathon 40 hour session you can have all the crap logged to a file that you can refer to
right from the first minute

[WaxfordSqueers]

-kl switch is applicable to windbg also and it has a much much bigger screen buffer use windbg -kl with all your windows in full glory

Thanks for info. I have no particular interest in the -kl switch but I came across an article by Microsoft on local kernel debugging in which they explained that the -kl switch worked only in debug mode.

I found it interesting that I could start wdbg with the -kl switch and get an immediate command prompt where I could enter commands like !process 0 0. Till then, the only way I knew of doing that was to load an app like notepad.

I discovered the -kl usage with windbg just after sending the past couple of messages and the !process 0 0 puts out a humungous amount of process and thread information. I was looking for a reference to the debugging mode session, especially for reference to kdcom.dll, which is apparently reliant on debugging extensions.

I can see how this will be very useful when applied to my USB driver stack problem between W10 and W7, using the USB extensions to locate breakpoints and so on.

I am curious as to whether kdcom.dll is an actual extension like those used in the debugger directory under winext. I'd like to have a serial extension like the USB extension I discovered that can spit out information about the USB stack.

My current interest is in using my serial problem to learn more about windbg and how it works. I would really like to dig into the debug target engine to see what is going on, while learning how to use windbg and kd effectively.

I read in an article that it is possible to set breakpoints in Windows drivers as it is booting and cut into the boot process. I can't imagine what kind of setup would allow that.

I was just reading about switching contexts in kd/wdbg. I recall with sice that you had to switch into the K32 context to set BPs but you could list the loaded modules using the 'table' command. Is there a similar command in kd/wdbg?

!process lists process and their threads but I'm looking to find the likes of ntoskrnl and its threads.

[blabberer]

kdcom.dll is not an extension as in windbg extension it is a native mode dll and is part of Operating System your os will not boot if it misses kdcom.dll

it imports from ntos and hal and exports debugging related functions like sending and receiving packets

you proabablyu have some misconceptions

you will never be able to find ntoskrnl and its threads ntoskrnl is not a process it is a part of os nothing will exist if there is no ntoskrnl

ntos does not /will not / cannot / have any threads

it is THE kernel module that implements all major functionality of Operating System

yes windbg can debug boot stage

you need to enable boot debugging

here is a break using sxe ibp this happens before any of the process has been started yet
not even system process has been started yet

it is at a place where BOOT OPTIONS are being checked and you can see kdcom
has been loaded this early along with ntos and hal

kd> r
eax=00000001 ebx=00000000 ecx=8080a188 edx=8293badc esi=8080a198 edi=00000029
eip=82bb15c8 esp=8293bb00 ebp=8293bca4 iopl=0         nv up ei pl nz na po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00200202
nt!InitBootProcessor+0x3d0:  <<<<<<

82bb15c8 8a4174          mov     al,byte ptr [ecx+74h]      ds:0023:8080a1fc=00


kd> dx ( nt!_LOADER_PARAMETER_BLOCK *) @ecx

( nt!_LOADER_PARAMETER_BLOCK *) @ecx                 : 0x8080a188 [Type: _LOADER_PARAMETER_BLOCK *]
    [+0x000] OsMajorVersion   : 0x6 [Type: unsigned long]
    [+0x004] OsMinorVersion   : 0x1 [Type: unsigned long]
    [+0x008] Size             : 0x88 [Type: unsigned long]
    [+0x00c] Reserved         : 0x0 [Type: unsigned long]
    [+0x010] LoadOrderListHead [Type: _LIST_ENTRY]
    [+0x018] MemoryDescriptorListHead [Type: _LIST_ENTRY]
    [+0x020] BootDriverListHead [Type: _LIST_ENTRY]
    [+0x028] KernelStack      : 0x8293c000 [Type: unsigned long]
    [+0x02c] Prcb             : 0x0 [Type: unsigned long]
    [+0x030] Process          : 0x0 [Type: unsigned long]
    [+0x034] Thread           : 0x82948340 [Type: unsigned long]
    [+0x038] RegistryLength   : 0x8c0000 [Type: unsigned long]
    [+0x03c] RegistryBase     : 0x81c05000 [Type: void *]
    [+0x040] ConfigurationRoot : 0x8080a2b0 [Type: _CONFIGURATION_COMPONENT_DATA *]
    [+0x044] ArcBootDeviceName : 0x80831380 : "multi(0)disk(0)rdisk(0)partition(2)" [Type: char *]
    [+0x048] ArcHalDeviceName : 0x808311c8 : "multi(0)disk(0)rdisk(0)partition(1)" [Type: char *]
    [+0x04c] NtBootPathName   : 0x80827e70 : "\Windows\" [Type: char *]
    [+0x050] NtHalPathName    : 0x80814c98 : "\" [Type: char *]
    [+0x054] LoadOptions      : 0x80813080 : " BOOTDEBUG  NOEXECUTE=OPTOUT  DEBUGPORT=COM1  BAUDRATE=115200  DEBUG" [Type: char *]
    [+0x058] NlsData          : 0x808d33e0 [Type: _NLS_DATA_BLOCK *]
    [+0x05c] ArcDiskInformation : 0x808180e8 [Type: _ARC_DISK_INFORMATION *]
    [+0x060] OemFontFile      : 0x838e41d0 [Type: void *]
    [+0x064] Extension        : 0x808313b8 [Type: _LOADER_PARAMETER_EXTENSION *]
    [+0x068] u                [Type: <unnamed-tag>]
    [+0x074] FirmwareInformation [Type: _FIRMWARE_INFORMATION_LOADER_BLOCK]
kd> !process 0 0 
**** NT ACTIVE PROCESS DUMP ****
NULL value in PsActiveProcess List
kd> lm
start    end        module name
80b9c000 80ba4000   kdcom      (deferred)             
8281c000 82c20000   nt         (pdb symbols)          e:\symbols\ntkrnlmp.pdb\00625D7D36754CBEBA4533BA9A0F3FE22\ntkrnlmp.pdb
82c20000 82c48000   hal        (deferred)

[WaxfordSqueers]

kdcom.dll is not an extension as in windbg extension it is a native mode dll and is part of Operating System your os will not boot if it misses kdcom.dll

it imports from ntos and hal and exports debugging related functions like sending and receiving packets

you proabablyu have some misconceptions

It's safe to say that I have a whole lot of misconceptions.

My understanding from reading Microsoft is that kdcom.dll is part of a trio. For a serial connection, kdcom is the man. For a firewire connection, kd1392.dll is the man and for a USB connection, kdusb.dll is the man.

They said nothing about kdcom doubling as a serial comm dll and a general packet go-between. However, since serial comm predated 1392 and USB by a significant degree, maybe it has been there all along with 1392 and usb being new kids on the block.

I have spent the last day or so studying the Intel Management system. Both my mobos, host and target, are Intel based and I can have both engines talking to each other. I had not realized till recently that the Intel engine is chip based, it's like a parallel processing system and a feature of interest is SOL, serial over LAN.

Apparently, the management engine can run without an OS loaded, which is interesting. That should mean serial comm is available before Windows loads, and hopefully during the boot phase.

However, while dabbling with such systems, the best laid plans of men and mice, aft gang aglay. While trying to get SOL going in Win10, I get an error message that it cannot start due to a lack of system resources.

WHAT!!!! Win10 with a lack of system resources!!!????. Apparently the rocket scientists at msoft have failed to address the issue of serial comm being traditionally on IRQ 3 and 4 only. Both my serial ports are already using those IRQs and although the INF file on my W7 allows for SOL allows for a wide range of IRQs, including 'any'. W10 has omitted that section from the INF file for SOL.

I never thought I'd see the day again where I had to juggle hardware IRQs and address ranges.

here is a break using sxe ibp this happens before any of the process has been started yet
not even system process has been started yet

it is at a place where BOOT OPTIONS are being checked and you can see kdcom
has been loaded this early along with ntos and hal

That's interesting. Where are you running wdbg/kd from? I told you about my cmd prompt running off an ease of access icon at logon but I wonder if there is a way to load wdbg/kd from a breakpoint in kdcom, maybe when it loads after ntoskrnl.

[WaxfordSqueers]

@blabberer

Success!!!

Established a net connection with wdbg between W7 laptop as host and W10 as target.

Did not expect it to break so early in the target boot. It broke before the boot screen where I select W10 or W7.

Practiced a few commands. Listed the modules and loaded symbols for modules like usbxhci, usbhub3, etc., that were deferred.

At the moment, don't really know where to go from here. When it first broke, there were only 3 modules loaded. I did not catch their names. By the time the target ran to the boot select window where I select W10, most of the modules were loaded.

Too late tonight, tomorrow is another day.

[blabberer]

congratulations
welcome to the club

as they say it is never late for old dogs to learn new tricks

[WaxfordSqueers]

congratulations welcome to the club

as they say it is never late for old dogs to learn new tricks

Arf!! Arf!!

Took a couple of days off. Wore myself out with the number of hour (weeks???) of futility encountered trying to establish a connection.

The Net connection was far from easy to solve. The host was indicating no debuggee present but I had a good Net connection between computers over which I could transfer files in either direction. On my system, my laptop is the host and connects to the router via wifi, running W7 SP1. The Target machine is a desktop running a dual booted system of W7 and W10. They are connected via a LAN CAT5 cable using RJ-45 connectors. Currently, I am using W10 as the debuggee (target).

When windbg was put into kernel debugging mode on the host, I could not get a connection.
Ran ipconfig /all on each machine and noted the IP4 address, marked 'preferred' on each Ethernet adapter section. I could not ping either of them from either machine. The command is ping -4 <address>, where <address> is the 192.168.xxx.xxx address noted for IP4 in the ipconfig listing of the machine you wish to ping. The -4 tells ping to look for an IP4 network connection.

Used 'arp -a' command to list networks available and their MAC address. The MAC address will identify the physical device connected, if you can find the MAC address. Some physical units have it marked on a label on the device. Could not see the IP4 address of either machine when arping from one to the other, even though I could transfer files fine under windows explorer under the Network folder.

Turns out that on my W10 network end the IP4 connection had reverted to the default connection, which gets it's IP address from the DHCP server. So, I went into Networks and Sharing under the 'change adapter settings' on each machine. On the host, it's ok to allow the IP4 connection to get it's IP address from the DHCP server since the server is at the router.

The router address on mine is 192.168.0.1 and that is also the default gateway. On the target, however, it can't use that default address if it is connecting to the Net over the the host wireless connection as on mine.

It's a two hat job. You have to put on your wireless hat when dealing with the wifi connection to the router, then onward to the Internet provider. When you deal with the network (LAN) you have to change hats and put on your LAN hat. On my host, there is a 'bridge' connection under 'change adapter settings' and it bridges the LAN connection from the target computer to the wifi on the host. Using that bridge, I get an Internet wifi connection on my target machine.

OK. I don't need a wifi connection on the target, I just need a LAN connection between host and target and over a certain port, which I chose as 55555. Microsoft recommends 50000 or so, but my addresses looked busy around there as revealed by my firewall activity manager. To establish the LAN connection I need the target to have it's own unique network address. If I let it set itself up to get addresses from the DHCP server, it will often use an address in the 169.xxx.xxx.xxx range which comes from outside.

It appears at one time that I had selected an address in range of my default gateway at 192.168.0.1 In ipconfig it was listed as 192.168.0.1XX. So I went into Network and Sharing/change adapter settings/Local Area Connection x, where x is the number of the LAN connection in use.

BTW...two other excellent network troubleshooting commands for a command window are 'netstat', which lists all IPs on a machine and the ports used by each, and 'route'. The latter is a complex command to use but you can use it to rebuild your entire network on a machine if it ever gets corrupted.

On the target, I right-clicked on the connection under 'change adapter settings', and found the IP4 entry in the lower table. I highlighted the IP4 connection and selected 'properties'. The IP4 connection was configured to 'obtain an IP address automatically', and that was the problem.

I clicked the radio button below to select 'Use the following IP address'. Then I entered my old 'static' IP4 address from ipconfig /all. If it is listed as a 169.xxx.xxx.xxx IP address it won't do, it has to start with 192.168.xxx.xxx. The 169.xxx.xxx.xxx IP address comes from a DHCP server via the router. DCHP addresses are dynamic, they change all the time. You want a static address which is fixed for the target machine and it will be configured as 192.168.xxx.xxx.

You can pretty well select any IP address between 192.168.0.1 to 192.168.0.255 as long as it does not conflict with the default gateway IP or other LAN IPs in that range. Some routers don't use 192.168.0.1 as a default gateway, so it's necessary to find out what a particular router is using. Sometimes it's written on a label on the router, or in the manual.

Anyway, I entered 192.168.0.xxx from my ipconfig /all listing and Windows complained it was for an old device and may cause a conflict. I knew that device was no longer there so I told it to accept that address. The moment it did, I was able to ping the IP4 address listed on either machine from either machine. And running arp -a on either machine listed those addresses as now being part of the network.

After that, windbg was happy. I might add that when setting up the 'Use this IP address' in the IP4 properties, that the config window shows an entry for 'subnet mask' and 'default gateway'. The subnet mask is configured by the system the moment you hit 'Enter' for the chosen static IP address. It will be something like 255.255.255.0. For the default gateway I chose the base IP address for my router, which is 192.168.0.1

Below that, in another window, are the DNS entries. You can leave that stock but I use 8.8.8.8 and 8.8.4.4, which I think is the Google DNS server. A DNS server changes an address like www.google.com to an numerical IP address like xxx.xxx.xxx.xxx.

Below the NS window is an Advanced button. It opens in a Window with three tabs, one of them marked 'WINS'. At the bottom of the WINS window are setting for Netbios. They advise you to use the middle one for static IPs, 'Enable Netbios over TCP/IP. I use that one.

BTW...Microsoft advises not to leave a machine in debug mode. I have no choice. With W10 in debug mode as target, it takes forever to load. I have heard that is normal with kernel debugging. I had to go into a cmd window and set bcdedit /debug off to get W10 back to a normal boot speed.

[WaxfordSqueers]

@blabberer

Success!!!

More success

Established a serial connection from W7 laptop as host to W7 target. I could have gone the VM route and I am going to explore it, but I could not use the physical net (LAN) connection because W8 and higher is required. The VM debugging technique will allow me to examine the W7 USB driver stack but it won't allow me to do that with my motherboard running the target OS. I may need that ability to see why my B360 chipset is not running W7 with USB 3 support.

The problem seemed to lie in my dual-boot configuration. I have W7 dual booted with W10 but had been using the W7 boot loader. I had not used W10 for a while but I noticed when I did use it W10 imposed it's own bootloader.

Decided to try my serial connection again and I setup W7 in debug mode with W10 debug off. When I rebooted the target, however, it ran into the W10 boot loader screen and on a whim I selected the Advanced options and forced debug mode from there. I also selected W7 as the default OS.

When I rebooted, it ran to the W10 logon screen at first (of course it would...I'd just selected debug mode for W10), which annoyed me, but the host wdbg indicated the debuggee running. I rebooted from W10 logon screen and when it started it was back in the old W7 boot loader with W7 marked in debug mode. So I selected W7 and it happily ran through logon to the desktop, whence I hit ctrl-break in the host and it broke on W7.

Seems there is something related to the W10 boot loader that enables serial debugging mode whereas the W7 boot loader route does not. In the future, I may have to boot with the W10 boot loader and repeat the process.

Here's the initial startup dialog. You can see the break where the host indicated it was shutting down. It started indicating W10 then after the shutdown it indicated W7.

Microsoft (R) Windows Debugger Version 10.0.17763.132 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

Opened \\.\com2
Waiting to reconnect...
Connected to Windows 10 17763 x64 target at (Wed Apr 17 19:31:17.449 2019 (UTC - 7:00)), ptr64 TRUE
Kernel Debugger connection established.

************* Path validation summary **************
Response Time (ms) Location
Deferred srv*c:\syms*http://msdl.microsoft.com/download/symbols
Deferred srv*c:\syms*https://msdl.microsoft.com/download/symbols
Symbol search path is: srv*c:\syms*http://msdl.microsoft.com/download/symbols;srv*c:\syms*https://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 10 Kernel Version 17763 MP (1 procs) Free x64
Built by: 17763.1.amd64fre.rs5_release.180914-1434
Machine Name:
Kernel base = 0xfffff804`096af000 PsLoadedModuleList = 0xfffff804`09aca790
System Uptime: 0 days 0:00:00.000
Break instruction exception - code 80000003 (first chance)
*******************************************************************************
* *
* You are seeing this message because you pressed either *
* CTRL+C (if you run console kernel debugger) or, *
* CTRL+BREAK (if you run GUI kernel debugger), *
* on your debugger machine's keyboard. *
* *
* THIS IS NOT A BUG OR A SYSTEM CRASH *
* *
* If you did not intend to break into the debugger, press the "g" key, then *
* press the "Enter" key now. This message might immediately reappear. If it *
* does, press "g" and "Enter" again. *
* *
*******************************************************************************
nt!DbgBreakPointWithStatus:
fffff804`0986a390 cc int 3
kd> g
KDTARGET: Refreshing KD connection
nvLDDMkm: Driver Registry Path = '\REGISTRY\MACHINE\SYSTEM\ControlSet001\Services\nvlddmkm'
nvAdapter: Device Registry Path = '\REGISTRY\MACHINE\SYSTEM\ControlSet001\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\0000'
nvAdapter:
nvAdapter: ***** CNvLAdapter* ffff9e8efe9c4000 -> DriverModel is 0x2300 ******
nvAdapter:
Shutdown occurred at (Wed Apr 17 19:37:04.035 2019 (UTC - 7:00))...unloading all symbol tables.

************* Path validation summary **************
Response Time (ms) Location
Deferred srv*c:\syms*http://msdl.microsoft.com/download/symbols
Deferred srv*c:\syms*https://msdl.microsoft.com/download/symbols
Waiting to reconnect...
Connected to Windows 7 7601 x64 target at (Wed Apr 17 19:37:33.784 2019 (UTC - 7:00)), ptr64 TRUE
Kernel Debugger connection established.

************* Path validation summary **************
Response Time (ms) Location
Deferred srv*c:\syms*http://msdl.microsoft.com/download/symbols
Deferred srv*c:\syms*https://msdl.microsoft.com/download/symbols
Symbol search path is: srv*c:\syms*http://msdl.microsoft.com/download/symbols;srv*c:\syms*https://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7601 MP (1 procs) Free x64
Built by: 7601.24387.amd64fre.win7sp1
Machine Name:
Kernel base = 0xfffff800`03e4e000 PsLoadedModuleList = 0xfffff800`04087c90
System Uptime: not available
nvLDDMkm: Driver Registry Path = '\REGISTRY\MACHINE\SYSTEM\ControlSet001\services\nvlddmkm'
KDTARGET: Refreshing KD connection
nvAdapter: Device Registry Path = '\REGISTRY\MACHINE\SYSTEM\ControlSet001\Control\CLASS\{4D36E968-E325-11CE-BFC1-08002BE10318}\0001'
nvAdapter:
nvAdapter: ***** CNvLAdapter* fffffa800df31000 -> DriverModel is 0x1100 ******
nvAdapter:
Break instruction exception - code 80000003 (first chance)
*******************************************************************************
* *
* You are seeing this message because you pressed either *
* CTRL+C (if you run console kernel debugger) or, *
* CTRL+BREAK (if you run GUI kernel debugger), *
* on your debugger machine's keyboard. *
* *
* THIS IS NOT A BUG OR A SYSTEM CRASH *
* *
* If you did not intend to break into the debugger, press the "g" key, then *
* press the "Enter" key now. This message might immediately reappear. If it *
* does, press "g" and "Enter" again. *
* *
*******************************************************************************
nt!DbgBreakPointWithStatus:
fffff800`03ee8400 cc int 3
0: kd>

[WaxfordSqueers]

I have been busy checking out the various modes of windbg. Feeling more comfortable with it now that I am getting onto customizing the workspace.

Stumbled across this interesting means of getting from the wdbg bp for an app just loaded through the load executable menu. wdbg stops the app in system code and entering

U $exentry

lists the OEP of app being loaded. In my case, I bp'd on the address supplied and when I hit G, it stopped right at the app entry point.

One issue I have yet to solve is how to quickly determine the context of the code in which I am tracing. In my current setup, I can tell I am in the current thread only by the address and call addresses supplied by wdbg with the app name prepended. However, when a system call is made, it's not always obvious which part is being called.

I have figured out how to open memory windows for esi, edi and eax (in 32 bit mode).

Right now I am examining a setup file for loading USB drivers. It's interesting how often it uses CPUID and I am getting an education in identifying processors by the CPUID return values. I am just using the 32 bit wdbg version since the setup file is 32 bit. At one point it compares values returned in eax to hard coded values representing different processors. I have identified the codes against certain processors and it is a bit-wise code with each bit or set of bits representing processor features.

I know ultimately the app is checking for 6th generation Intel processors but as yet I don't know if it is rejecting newer processors. I have to determine the reason for using several different cmp instructions with jumps to different areas of the code.

Worked out the USB 2 and 3 stacks basically as to the theory. Next I need to examine the structures in wdbg to get a deeper meaning of how the drivers/devices interact.

I do know this, My usbxhci driver for the host controller has not been supplied a PDO by the PCI bus driver. It has been enumerated and loaded in memory but without the PDO it cannot load the hub driver in the USB stack. If the hub driver doesn't load, the USB ports can't be connected to the hub.

[WaxfordSqueers]

Is there no way to attach to an application on the target, or start it remotely, with full kernel debugging power, from a host computer?

If I run !process 0 0, I can see the target app but it seems I cannot attach to it remotely.

Am I missing something or is that not allowed with remote kernel debugging?

[blabberer]

host
sxe ld foo.exe
g

target double click foo.exe

windbg will break on loading the exe

reload symbols

set process specific breaks as reqd bp /p {eproc } [module!symbol]

btw keep in mind sxe ld will work only once per boot for one specific binary