Register says DFS is wrong... 68 plus 10

Pah, that's just a kernel oops. Nothing to see there, it happens on flakey hardware or when a kernel module goes breasts up. (Seen loads of them, but then, you see a lot of flakey RAM in a system builders over the years) Occasionally a rare combination of events may cause one in a stable kernel on good hardware, but then, that's what they're there for. So they can be used to isolate the cause and fix it, quickly. I notice mr doofy only gave errors like the ones below rather than the text from a blue screen of rest... And ooops is after all a mini-panic. And a kernel panic is analogous to... you guessed it, the BSoD. (oops means "I've failed somewhere but not crashed, but don't count on my environment being consistent, it's probably best to reboot but I'll try to keep going for as long as possible")

Sometimes, the kernel manages to return to a stable state after an oops, but is it worth the risk?

Does a BSoD confer any useful information to you Doofy? Didn't think so. Comparing apples with elephants again, dfs?

One was a kernel oops, inside that message was a complete backtrace, register and stack dump to aid in locating and fixing the problem. There're programs you can dump a kernel oops text into that'll analyse it and come up with more user readable information too, but that stuff is for developers, and for users to send TO kernel developers if they detect a bug. What does

tell you about what actually FAILED in the program?

Or that

Or that?

Exactly. I think he just shot himself in the foot with those examples.

Since when was DFS ever worth anything other than something to argue with to pbutt the time, and take the pee out of?

Let's just say this, the errors and messages in the windows logs are worse why, what it was trying to do when it failed, what state it was in when it failed.

If there is a more verbose logging mechanism in windows, where is it? Why is it not ACTIVE by default? Where are these oh so wonderful windows process utilities like ps, top, strace, ltrace, gdb, etc?

gdb is so good it'll even tell you the exact line in the source code the program failed at if you compiled in the debugging symbols. From there it's simply a matter of looking at the variables at the point of failure and backstepping to the point the thing went breastsup.

Oh, I'm sorry, I keep forgetting windows is so limited it doesn't even include a compiler as part of the base install. Let alone a debugger. You've gotta pay through the nose for that stuff, because you can't abide free software.

Then again, it WILL not, y'mean. Those things are all but worthless.