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/


BugCheck 51

cm_itcm_it Member - All Emails Posts: 3
HI,

I'm new here. i'm a sys admin for a living. My main focus is SCCM, AD, Powershell, WPA. I have used WinDB in the past to solve a USB issue. I had a look into some basic commands and with a lot of patience i was able to solve the issue. Windb kept my interest. The only downside for me is the lack of a good introduction into it.

Anyway, i have a computer that has the following bugcode: BugCheck 51
It appear to be caused by the registry.

I found this article online: https://vallejo.cc/2015/03/23/debugging-bsod-trying-to-delete-malformed-registry-key-on-windows-8-1/

i tried to follow it but his stack is pretty different from mine. Add to that the fact that my knowledge of commands is low, its pretty hard to follow.

how do i start debugging this? is there any documentation that explain this mans reasoning and maybe the basic idea behind it? I get that he unravels the code from memory but i don't understand the "parameter and pointers" part nor how they are linked.

So i guess i'm asking for a place with more guides/tutorials/documentation that walks you trough a bit more.

I could upload my BSOD if someone would like to make some sort of "walkthrough".

cheers

Comments

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,483
    [email protected] wrote:
    > I'm new here. i'm a sys admin for a living. My main focus is SCCM, AD, Powershell, WPA. I have used WinDB in the past to solve a USB issue. I had a look into some basic commands and with a lot of patience i was able to solve the issue. Windb kept my interest. The only downside for me is the lack of a good introduction into it.
    >
    > Anyway, i have a computer that has the following bugcode: BugCheck 51
    > It appear to be caused by the registry.
    > ...
    > i tried to follow it but his stack is pretty different from mine. Add to that the fact that my knowledge of commands is low, its pretty hard to follow.
    >
    > how do i start debugging this?

    Well, I don't mean to be a Negative Nellie, but I think the practical
    answer is "you don't".  Either there is bad information written to the
    registry, or something nefarious is mangling the data on the way in.  If
    there is bad information written to the registry, then the solution is
    to reload the registry from a backup, or reinstall Windows.

    If something is mangling the data, then you have a memory error or a
    virus.  You can test for memory problems, but a virus will require a
    reinstall.

    --
    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • cm_itcm_it Member - All Emails Posts: 3
    It's not a virus, i'm sure of that.
    Having said that, i wanted to use this particular case as a learning-moment.
    We have spare computers enough so it's already replaced, i have no time pressure solving this.

    I just wanted to try and come up with a WinDB analysis like the one i referred to. And on the other hand i was hoping on some resources that can help me to learn some new stuff.

    The resource i'm looking for kinda explains the general idea behind de debugger. Like i know how to list the modules, ask for computer specs, see the stack, find the last frame. But i can't "interact" with the stack, i don't really know what i'm looking at and for (a part from what i believe are memory addresses).

    But i haven't found documentation that explains really.

    Thanks for your reply btw
  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,302
    I teach lots of people how to debug Windows crash dumps. It's not easy as
    there's TONS of information you need in order to really get proficient at
    it. Assuming that we're talking about general purpose kernel debugging, I've
    found that it requires a mix of the following:

    1. Understanding of the C programming language

    2. Understanding of assembly

    3. Understanding of the Windows operating system (overall architecture, core
    concepts)

    4. Understanding of computer architecture

    5. Patience and perseverance...Crash dumps analysis is hard and it takes a
    certain kind of to person get up and put their pants on day after day
    knowing that they're going to stare at the same problem again.

    I try to jump start everyone with this stuff during our 5 day debug lab
    (except #5, you need that already :)). I don't know of anywhere you can go
    to read an A-Z "this is how you get into kernel debugging."

    That being said, if you put the dump someplace I can try to walk through it
    if you don't mind me sharing the result.

    -scott
    OSR
    @OSRDrivers

    wrote in message news:[email protected]

    It's not a virus, i'm sure of that.
    Having said that, i wanted to use this particular case as a learning-moment.
    We have spare computers enough so it's already replaced, i have no time
    pressure solving this.

    I just wanted to try and come up with a WinDB analysis like the one i
    referred to. And on the other hand i was hoping on some resources that can
    help me to learn some new stuff.

    The resource i'm looking for kinda explains the general idea behind de
    debugger. Like i know how to list the modules, ask for computer specs, see
    the stack, find the last frame. But i can't "interact" with the stack, i
    don't really know what i'm looking at and for (a part from what i believe
    are memory addresses).

    But i haven't found documentation that explains really.

    Thanks for your reply btw

    -scott
    OSR

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,483
    "[email protected] windbg"@lists.osr.com wrote:
    > Having said that, i wanted to use this particular case as a learning-moment.
    > We have spare computers enough so it's already replaced, i have no time pressure solving this.
    >
    > I just wanted to try and come up with a WinDB analysis like the one i referred to. And on the other hand i was hoping on some resources that can help me to learn some new stuff.

    In this particular case, windbg may not be the right tool.  If you are
    really interested in a project, you can try reverse engineering the
    format of the registry files, to see if you can find where the flaw
    exists.  There are documents on the web that would help with that.  I
    still doubt you can fix it; you may find that a whole sector was written
    as 0s, for example, and that's not really recoverable.


    > The resource i'm looking for kinda explains the general idea behind de debugger. Like i know how to list the modules, ask for computer specs, see the stack, find the last frame. But i can't "interact" with the stack, i don't really know what i'm looking at and for (a part from what i believe are memory addresses).

    Well, you can't really "interact" with the stack.  You can disassemble
    code, you can change registers, and you can tweak memory values, but
    once you have a bugcheck, the system is hosed.  You can't "resume"
    execution in any meaningful way.

    --
    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • cm_itcm_it Member - All Emails Posts: 3
    >1. Understanding of the C programming language
    I don't know C.

    >2. Understanding of assembly
    RIP

    >3. Understanding of the Windows operating system (overall architecture, core
    >concepts)

    I've read quite a few chapters of Windows Internals books, so i have a frame of reference.

    >4. Understanding of computer architecture
    Again, some frame of reference.


    >5. Patience and perseverance...Crash dumps analysis is hard and it takes a
    >certain kind of to person get up and put their pants on day after day
    >knowing that they're going to stare at the same problem again.
    Thats no issue, i've done this in the past. For instance, on my small (very personal) blog: https://cookiecrumbles.github.io/BSOD-all-over-the-place/

    I've done that analysis based on whatever i could find on the net, took me a lot of time tho.


    >I try to jump start everyone with this stuff during our 5 day debug lab
    >(except #5, you need that already :)). I don't know of anywhere you can go
    >to read an A-Z "this is how you get into kernel debugging."

    Well i'm not gonna get money from my bosses for a 5-day training for something i'm not gonna use that often (at least at this job).
    And i'm concluding that i'm not gonna find more info on the net than i already did?

    >That being said, if you put the dump someplace I can try to walk through it
    >if you don't mind me sharing the result.

    I don't have a case atm. But maybe you have some cases (in the forum) that can learn me a few things ?

    Thanks for the reply and info. Sorry for the late response but it's pretty busy atm.
  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,302
    Your blog post shows you're on the right path, lots of picking through
    structures and jumping to some logical conclusions. From an IT perspective
    you're mostly trying to come up with reasonable things to try to help
    resolve the problem (e.g. "this is a crash in the file system, so let me
    check the timestamp on the AV drivers and see if there's an update").

    I try to write about debugging related things when I can (debugging it
    somewhat of a hobby of mine...):

    https://www.osr.com/blog/category/debug/

    The ntdebugging blog always did a nice job on their crash walkthroughs,
    though they haven't updated in a while:

    https://blogs.msdn.microsoft.com/ntdebugging/

    Maybe others have more.

    -scott
    OSR
    @OSRDrivers

    wrote in message news:[email protected]

    >1. Understanding of the C programming language
    I don't know C.

    >2. Understanding of assembly
    RIP

    >3. Understanding of the Windows operating system (overall architecture,
    >core
    >concepts)

    I've read quite a few chapters of Windows Internals books, so i have a frame
    of reference.

    >4. Understanding of computer architecture
    Again, some frame of reference.


    >5. Patience and perseverance...Crash dumps analysis is hard and it takes a
    >certain kind of to person get up and put their pants on day after day
    >knowing that they're going to stare at the same problem again.
    Thats no issue, i've done this in the past. For instance, on my small (very
    personal) blog: https://cookiecrumbles.github.io/BSOD-all-over-the-place/

    I've done that analysis based on whatever i could find on the net, took me a
    lot of time tho.


    >I try to jump start everyone with this stuff during our 5 day debug lab
    >(except #5, you need that already :)). I don't know of anywhere you can go
    >to read an A-Z "this is how you get into kernel debugging."

    Well i'm not gonna get money from my bosses for a 5-day training for
    something i'm not gonna use that often (at least at this job).
    And i'm concluding that i'm not gonna find more info on the net than i
    already did?

    >That being said, if you put the dump someplace I can try to walk through it
    >if you don't mind me sharing the result.

    I don't have a case atm. But maybe you have some cases (in the forum) that
    can learn me a few things ?

    Thanks for the reply and info. Sorry for the late response but it's pretty
    busy atm.

    -scott
    OSR

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