Windows 7 Forums
Welcome to Windows 7 Forums. Our forum is dedicated to helping you find support and solutions for any problems regarding your Windows 7 PC be it Dell, HP, Acer, Asus or a custom build. We also provide an extensive Windows 7 tutorial section that covers a wide range of tips and tricks.


Windows 7: Recurring BSOD Problem

03 Oct 2009   #21
chuckr

XP_Pro, W7_7201, W7RC.vhd, SciLinux5.3, Fedora12, Fedora9_2x, OpenSolaris_09-06
 
 

Quote   Quote: Originally Posted by H2SO4 View Post
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.
Quote:
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...)
Quote:
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'...

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

Quote:
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 (n) 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'!

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

Quote:
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:

Quote:
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.
Quote:
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)?
Quote:
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.

Quote:
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


My System SpecsSystem Spec
.
03 Oct 2009   #22
H2SO4

Win7x64
 
 

Quote   Quote: Originally Posted by chuckr View Post
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.
 
Quote   Quote: Originally Posted by chuckr View Post
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!

Quote   Quote: Originally Posted by chuckr View Post
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".
 
Quote   Quote: Originally Posted by chuckr View Post
But the "fact" is, that it did happen, the (n) 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.
 
Quote   Quote: Originally Posted by chuckr View Post
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.
 
Quote   Quote: Originally Posted by chuckr View Post
...
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.
 
Quote   Quote: Originally Posted by chuckr View Post
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
My System SpecsSystem Spec
Reply

 Recurring BSOD Problem




Thread Tools




Similar help and support threads
Thread Forum
Recurring events in outlook stop recurring
We have multiple conference rooms with resources in active directory so we can schedule meetings in the conference rooms. Recently, I'm not sure for how long, whenever someone creates a recurring event with no end date when you go into the event on the conference room calender it only shows...
Microsoft Office
Recurring Updates Problem
I recently started having issues running Windows Updates on my beautiful Dell E6400. The error is 80070002 and I have gone through this process a few times. After doing so, I'm able to run updates, but only once. Each subsequent attempt to run updates gives the same error. Windows 7...
Windows Updates & Activation
File name too long recurring big problem
In Windows 7, I have the frequent problem of not being able to move some items in large projects from my main drive to a portable USB drive because of too long file name. It's a big problem. I tried moving in stages but this doesn't always work. Even worse, I often can't figure out where to...
General Discussion
Recurring problem with dowloading anything in Windows 7
When I first bought my W7 machine, I had no problems downloading. Right-click, save as, and it worked. But all of a sudden, in both IE and Firefox, it won't download anything. The save window won't even appear in IE, and the downloads window in FF will appear, but under the file, it just says...
Browsers & Mail
Recurring Problem with Updates
I have 2 computers with Windows 7. My laptop has Professional and my netbook has Starter. The problem I'm having is with the Starter version. Every other time I boot up, I get the message that Windows is configuring updates. It finally times out and says that the update failed. It finishes...
Windows Updates & Activation
Recurring Problem
My damn comfuser keeps having a problem w/(what I think is) malware. But even after using Malwarebytes' & manual cleaning, the problems come back. I don't know what to do & was hoping someone can look at my Hijackthis! result & give me some direction please.
BSOD Help and Support


Our Sites

Site Links

About Us

Find Us

Windows 7 Forums is an independent web site and has not been authorized, sponsored, or otherwise approved by Microsoft Corporation. "Windows 7" and related materials are trademarks of Microsoft Corp.

Designer Media Ltd

All times are GMT -5. The time now is 20:58.
Twitter Facebook Google+ Seven Forums iOS App Seven Forums Android App