BugCheck 51

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

xxxxx@gmail.com 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, xxxxx@probo.com
Providenza & Boekelheide, Inc.

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

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:xxxxx@windbg…

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

"xxxxx@gmail.com 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, xxxxx@probo.com
Providenza & Boekelheide, Inc.

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

  1. Understanding of assembly
    RIP
  1. 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.

  1. Understanding of computer architecture
    Again, some frame of reference.
  1. 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.

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:xxxxx@windbg…

  1. Understanding of the C programming language
    I don’t know C.
  1. Understanding of assembly
    RIP
  1. 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.

  1. Understanding of computer architecture
    Again, some frame of reference.
  1. 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.