Recurring BSOD Problem

[chuckr]

From post # 18:
... Hence, the warning above is spewed by the debugger as a generic reminder that at least some of the values may not be accurate.
(R)IP is obviously essential though - so we can get back to where we left off when the handler's done - and it'll absolutely be saved every time.

Indeed it will - that was originally 'created' by the hardware CPU, along with BP.
And, in the case of an interrupt (for sure), Flags also.

In the OPs case, the RIP value is undeniably populated and pointing close to where it should, albeit off-by-one byte: etc.

Right, The IP does point to the (erroneous) instruction-bytes, and, is OFF by +1 from where it should be. (Which may be the result of the previous instr, EXECUTING to completion)

Interesting that the 'real-time' debugger works by injecting a 1-byte hex 'CC' code into the instruction where you've set the initial Break.
Saving the real 'first-byte' of the opcode, until the Debugger gets control, via the 'Int3's Interrupt handler (CS:IP in a hw vector table).
After you click what you want, DBGR restores 'first-byte', decrements IP, and the hex 'CC' goes where-ever nec. for the next Bkpt/Single-Step/etc.
(Mentioned here, only because of the mental 'parallel-association' of the +/- 1 mechanism...)

For what it's worth, I don't believe it works that way. From a software point of view, IP updates are an atomic operation, and the OS will never be able to watch the IP "count" incrementally between two valid instruction offsets.

But here is one of your boundaries: the software point-of-view. Agreed that there it is 'atomic'.
Supposedly, the 'Test-and-Set' instr is too, for semaphores, Critical-sections, etc.

Neither the OS, nor any software (ie single Intel Instruction) is able to watch the IP "count".
Impossible... This is the hw 'doing its thing', internally, where software point-of-view is 'Not-Applicable'.
Like watching your analog clock's "minute-hand" tick:
The internal mechanics are NOT frozen dead, from one tick to the next.
'Something' is happening in there...

To enter (dig-into) the next logical step 'further down', you have to look at what the hardware is actually doing -between- opcodes. i.e. actually -executing- the last opcode.
One of those functions is to update the IP iaw instruction-LENGTH. Where does this come from? The hw...
More duties are to fetch something from somewhere (or ADD, MUL, or store something somewhere), whatever the opcode 'does'...

..... If I were a professional, I'd 'Instruction_Breakpoint' at 7f3e....
Without wishing to be seen to be buttering up a forum heavyweight, it's very obvious that you're very professional.

By that I meant 'gainfully employed'...
Useful to society , so to speak, working (govt) state-of-the-art again.
(I left your quote in, because I -liked it- Thank you.) I was, and like to think that I still am.

Oh sure, software can directly walk the IP all over the place (the debugger does it all the time), but the point is that the code in question does nothing to directly shunt the IP one byte further along than it should be.

Agreed, and that is exactly the point. (Looking only from the sw pov)
But the "fact" is, that it did happen, the bytes instruction is shown as (n-1) bytes long, therefore the 'glitch'...
The hw (cpu) did what it was supposed to do: Fetch the instr from location IP, and 'execute it'!

Perhaps the thread was pre-empted and its context record was damaged,

We know that the threads get pre-empted all the time, but where are these Context-records? I assume they're some sort of Data-structure, but they must be, by definition, associated with their resp. thread. AND, moved about...
Here -- Memy/transfer-path, pick/drop bits?
There -- CPU, lost 1 nano-clock-cnt during byte-block-xfer?
and Everywhere -- everything else...

but the chances are very small that the stored RIP value merely got INCed (or similar).

Very small, but still a 'chance'. (From a Hardware point-of-view: Not Atomic, but progressively, in minute (mynoot) time-increments).
==============================================================

From post # 20:

Sure, "[rsi]" is equivalent to "[rsi+00h]", if that's what you mean. That's just the way WinDBG chooses to present the disassembled mnemonics.

Yes, that's what I meant - it seemed 'hidden' before the others.
The disassembled mnemonics should be in-order of the actual binary-code.
I would think the order is the result of 'compiler-optimization'.
I'd consider coding a REP instr for -n- times,
then do the 'special-case' of: +20h, BP (not knowing about DI and the +20h, right now).
If it were my code, and it looked like a 'go', I'd tweak it.

Is it 'normal' for 64-bit code to be using Dword pointers?

I don't think I understand where you're seeing the 32-bit pointer(s)?

0: kd> u fffff880`014e7f10 L12
ndis+0x1f10:
014e7f10 0041ff add byte ptr [rcx-1],al
014e7f13 842c94 test byte ptr [rsp+rdx*4],ch
014e7f16 0100 add dword ptr [rax],eax
014e7f18 00ff add bh,bh
014e7f1a 15 b9310500 adc eax,531B9h
014e7f1f 488b f0________ mov rsi,rax

014e7f22 4885 c0________ test rax,rax
014e7f25 0f84 aa010000__ je ndis+0x20d5 (014e80d5)

014e7f2b 4885 f6________ test rsi,rsi
014e7f2e 0f84 3a020000 je ndis+0x216e (014e816e)

014e7f34 448b642450_____ mov r12d,dword ptr [rsp+50h]
014e7f39 4c8b6c2430_____ mov r13,qword ptr [rsp+30h]

014e7f3e 4885 f6________ test rsi,rsi
014e7f41 0f84 13840100__ je ndis+0x1a35a (0150035a)

014e7f47 4889 3e________ mov qword ptr [rsi],rdi <===< mov qword ptr [rsi+00h],rdi

Above...
Just seemed strange to me to see that in 64-bit code... What's the blue 'd' ?
Sorry you had to type in all that relative-displacement stuff.

Originally Posted by chuckr
Since you like this stuff, is there any way that you could execute this "chunk" of code under 'controlled' circumstances?


Sure, no problem. I can run it under a kernel debugger and thus control its operation. If you like, you can drive. Let me know what breakpoints you'd like set and I'll paste back the results. Good geeky fun

Was getting late; Meant: 'can one do that, with a chunk-of-code'...
Thank you for the kind offer though (may take you up on that )...
====================================================================

That should 'wrap-up' this isolated thread, which wasn't moved to the new area.

Seem to recall 'Compiler-output' and "object-modules/executable", etc.
Must be in new area...
(Check wikipedia for "object_modules"...)
Or, somewhere around here, bottom para.:
Using the GNU Compiler Collection (GCC)

Chuck

 

[H2SO4]

Saving the real 'first-byte' of the opcode, until the Debugger gets control, via the 'Int3's Interrupt handler (CS:IP in a hw vector table).
After you click what you want, DBGR restores 'first-byte', decrements IP, and the hex 'CC' goes where-ever nec. for the next Bkpt/Single-Step/etc.
(Mentioned here, only because of the mental 'parallel-association' of the +/- 1 mechanism...)

Yes, that's how the debugger does "software" breakpoints. As you're probably aware, it uses a different mechanism to implement "hardware" breakpoints - the processor's debug registers (DR0, DR1, DR2...). Needless to say, the OP's machine presumably wasn't running under a kernel debugger at the time of the crash, so the chance of encountering a CC (INT3) breakpoint should be zero.
　

But here is one of your boundaries: the software point-of-view. Agreed that there it is 'atomic'.

Being primarily interested in software, I have neither the knowledge nor the equipment to examine the processor's inner workings. From my (software) point of view, once there is sufficient evidence to conclude that the IP is not where it should be given the software instructions, I'm content to designate the hardware as being "unreliable" and move on to the next software issue. If you'd be willing to do a write-up on how to diagnose which bit of hardware may be at fault here, I'll read it with gusto!

By that I meant 'gainfully employed'...
Useful to society , so to speak, working (govt) state-of-the-art again.

I gather that you're unable to find the type of work you'd want. That is sincerely upsetting to me. There's something very wrong with society when somebody with your knowledge is unable to be "gainfully employed".
　

But the "fact" is, that it did happen, the bytes instruction is shown as (n-1) bytes long, therefore the 'glitch'...
The hw (cpu) did what it was supposed to do: Fetch the instr from location IP, and 'execute it'!

Sure, there's no evidence that the processor itself was at fault. The IP could have been off for any number of reasons. It's just that in the absence of likely software causes, hardware is almost always the culprit, hence my suggestion to the OP to treat their hardware with suspicion. As I suggested previously, I have no means of telling whether it's the processor, RAM, motherboard, or some other hardware component.
　

We know that the threads get pre-empted all the time, but where are these Context-records? I assume they're some sort of Data-structure, but they must be, by definition, associated with their resp. thread. AND, moved about...

Yes, a struct in memory. I wrote a short explanation in that BSOD primer in the "crashes" section of the forum, if you're interested.

In short, while it's theoretically possible that the thread's CONTEXT record, and more specifically its IP, was damaged by software causes while the thread was not running, that is a rare event. Even rarer is a situation where the IP stored in the thread's context is not just obliterated with gibberish but merely INCed by 1, while all the other registers look reasonably intact. IP misalignment is almost always a hardware thing in such a situation.
　

...
014e7f34 448b642450_____ mov r12d,dword ptr [rsp+50h]
...
Above...
Just seemed strange to me to see that in 64-bit code... What's the blue 'd' ?

　
Ah, that. It's not a DWORD pointer - it's a pointer to a DWORD. The instruction says "move the 4 bytes starting at offset RSP+50h into the least-significant 4 bytes of the R12 register." Hence, the 4 bytes being copied are effectively data, not a direct reference to a memory address.

On x64, the 8 new general purpose registers (R8 thru R15) are of course 64 bits wide. To refer to the least significant DWORD, the 'd' suffix is appended: R12D. R12W would be the lowest word, and R12B is the lowest byte.

To put it another way, R12D is to R12 what EAX is to RAX.
　

Was getting late; Meant: 'can one do that, with a chunk-of-code'...
Thank you for the kind offer though (may take you up on that)

　
The easiest way to execute that code under a debugger would be to simply put a breakpoint at the beginning of the function and wait. According to the function name (NdisAllocateNetBufferList), this code should be getting traversed relatively frequently, so it shouldn't take long for the breakpoint to fire.

Again, a very interesting conversation - thank you