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_sykesmatt_sykes Member - All Emails Posts: 290

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...

Comments

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,911
    edited February 2019

    (completely off-topic)

    really obstreperous target machine

    +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

  • matt_sykesmatt_sykes Member - All Emails Posts: 290

    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! )

  • matt_sykesmatt_sykes Member - All Emails Posts: 290

    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'.)

  • raj_rraj_r Member - All Emails Posts: 983
    via Email
    polynesia is really obstreperous said doctor dolittle
  • matt_sykesmatt_sykes Member - All Emails Posts: 290

    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.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

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 Mar 2020 OSR Seminar Space
Developing Minifilters 15 Jun 2020 LIVE ONLINE
Writing WDF Drivers 22 June 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA