Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.More Info on Driver Writing and Debugging
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
Got a really obstreperous target machine, just wont stay in the debugger
matt_sykes
Member - All Emails Posts: 291
Odd one this, never seen it before:
This is running on a DHCP network, the target NIC supports network debugging, the host has been used successfully many times over the years to debug targets. (The target is a client machine)
As you can see it gets stuck in OK:
Waiting to reconnect...
Connected to target 192.168.203.2 on port 50000 on local IP 192.168.203.1.
You can get the target MAC address by running .kdtargetmac command.
Connected to Windows 10 17134 x64 target at (Mon Feb 18 11:57:57.242 2019 (UTC + 0:00)), ptr64 TRUE
...
it broke (I dont know why, it hasnt debugged before so wont have an initial breakpoint set, could be a clue) so I put in a kdfile:
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:
fffff802`e4a3ecf0 cc int 3
0: kd> .kdfiles c:\drivers.txt
KD file associations loaded from 'c:\drivers.txt'
0: kd> g
KDTARGET: Refreshing KD connection
At this point it fell off the debugger. The resynch doesnt help either. Something very fish is going on...
Howdy, Stranger!
| Upcoming OSR Seminars | ||
|---|---|---|
| OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead! | ||
| Kernel Debugging | 30 January 2023 | Live, Online |
| Developing Minifilters | 20 March 2023 | Live, Online |
| Internals & Software Drivers | 17 April 2023 | Live, Online |
| Writing WDF Drivers | 22 May 2023 | Live, Online |
Comments
(completely off-topic)
+1 for the use of "obstreperous" in a sentence.
+1 for properly putting an "ly" at the end of an adverb.
Peter
(ETA: as an aside... I am now doubting my initial judgement that "really" is an adverb in that sentence. Rather, I'm pretty sure it's an adjective! But it still needs the "ly", which Mr. Sykes provided... so the points stand).
Peter Viscarola
OSR
@OSRDrivers
Turns out the BIOS had 'legacy ROM' enabled.
It never ceases to amaze me how computers can screw themselves up....
(A colleague used to joke, they are 'non deterministic infinite state machines', he wasnt wrong here! )
Oh, and Peter, an adverb describes a verb, so in 'run quickly', quickly is an adverb. 'Really' is therefore an adjective, (well, it amplifies an adjective, 'really obstreperous'.)
It is still being a bit of a PITA, occasionally failing now, not all the time, so from some of the traces in windbg I disabled the 'Windows Server Solutions Computer Restore Driver' in device manager, and it looks to be working perfectly now.
Never heard of this 'feature' before, and no idea what it does. The associated services are not on the machine though (it is a clients PC, so could be in any state), and there isnt much documentation on this 'feature' on the net. Anyway, disabling it hasnt caused any problems.