Jump to content

Blue Screen of Death Error, IRQL_NOT_LESS_OR_EQUAL 0x0000000A


Recommended Posts


Posted

Since you've seen the other post, I won't go into many details, but it looks like the AVG layered service provider (LSP) network filter driver was at fault here. There was obviously a network request work item on this machine that either did not complete, or a socket operation timed out - either way, the TCP TCB has timed out, and is being closed. As with most LSP filter drivers, any activity on the tcp stack in TCPIP.sys (network-related or otherwise) filter through it, and it looks like avg's filter driver came in and did something (can't tell what) as would be expected with AVG installed. Once it's done handling this request as it passes through, it has to send it off to afd.sys to be handled - except, it appears that the driver has munged the ecx register that is being registered by the KeAcquireInStackQueuedSpinLock, and thus the machine is going to bugcheck. See:

0: kd> .bugcheck
Bugcheck code 1000000A
Arguments 000000e8 00000002 00000001 806e6a16

0: kd> k
ChildEBP RetAddr
805510b8 804fc4aa hal!KeAcquireInStackQueuedSpinLock+0x26
805510d8 b4b0bf95 nt!KeInsertQueueApc+0x20
80551108 804f16c0 afd!AfdRestartConnect+0x172
80551138 b4b1fcb1 nt!IopfCompleteRequest+0xa2
WARNING: Stack unwind information not available. Following frames may be wrong.
805511b4 804f16c0 avgtdix+0x1cb1
805511e4 b4b63942 nt!IopfCompleteRequest+0xa2
805511fc b4b69471 tcpip!TCPDataRequestComplete+0xa6
80551210 b4b6f1be tcpip!TCPRequestComplete+0x12
8055123c b4b69491 tcpip!CloseTCB+0x1ad
80551258 b4b6f80b tcpip!DerefTCB+0x60
805512d0 b4b5f3ec tcpip!TCBTimeout+0x7ec
805512e0 8050220f tcpip!TCBTimeoutdpc+0xf
805513fc 8050232b nt!KiTimerListExpire+0x14b
80551428 80545e7f nt!KiTimerExpiration+0xb1
80551440 8055be60 nt!KiRetireDpcList+0x61
80551450 80545d64 nt!KiIdleThread0
80551454 00000000 nt!KiIdleLoop+0x28

// The registers showing the register addresses - note ecx is within the first 64k, and as
// you know from the post you linked, that memory is PAGE_NO_ACCESS:
0: kd> r
eax=805510cc ebx=8980e870 ecx=000000e8 edx=805510cc esi=00000000 edi=8980e870
eip=806e6a16 esp=805510b8 ebp=805510d8 iopl=0 nv up ei pl nz ac po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010212
hal!KeAcquireInStackQueuedSpinLock+0x26:
806e6a16 8711 xchg edx,dword ptr [ecx] ds:0023:000000e8=????????

// Here's the eip register unassembled, so you can see why ecx being invalid is bad:
0: kd> u eip
hal!KeAcquireInStackQueuedSpinLock+0x26:
806e6a16 8711 xchg edx,dword ptr [ecx] <- // Trying to write to ecx from the memory address pointer in edx
806e6a18 83fa00 cmp edx,0
806e6a1b 7507 jne hal!KeAcquireInStackQueuedSpinLock+0x34 (806e6a24)
806e6a1d 83c902 or ecx,2
806e6a20 894804 mov dword ptr [eax+4],ecx
806e6a23 c3 ret
806e6a24 83c901 or ecx,1
806e6a27 894804 mov dword ptr [eax+4],ecx

// The AVG module in question:
0: kd> lmvm avgtdix
start end module name
b4b1e000 b4b36900 avgtdix T (no symbols)
Loaded symbol image file: avgtdix.sys
Image path: avgtdix.sys
Image name: avgtdix.sys
Timestamp: Wed Dec 10 06:50:42 2008 (493FAD12)
CheckSum: 0001B178
ImageSize: 00018900
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4

I believe that is the latest version, so if you're stuck using AVG I'd suggest reporting this to their support folks to fix. However, if you are OK using another A/V vendor, consider removing AVG and using a more stable package.

Posted (edited)

That was a great, detailed answer, thank you.

I have two questions: One, how can I figure that out myself? Would be useful to know how to debug this type of error.

Two, do you have an idea of what to use to replace AVG then? I have used it for years and I especially appreciate the fact that it doesn't seem to make my system go much slower (unlike the big evil programs such as McAfee and Norton).

Thanks!

---EDIT:

P.S. Would trying this LSP fix help? http://www.cexx.org/lspfix.htm

If it could be related to software I've recently installed, that might repair something. I installed Winpcap and then uninstalled it a week or so ago, if that might be the problem. EDIT2: LSP fix didn't seem to find any problems, but that was after completely uninstalling winpcap (i actually just disabled/(set to manual) the service before).

Edited by kopf1988
Posted
how can I figure that out myself?

windbg and knowledge about the system's internals. Debugging simple errors is easy, but doing fairly advanced/in-depth analysis and really understanding what is going on (there are degrees of difficulty obviously) is a lot harder.

Anyways. I've never been a big fan of AVG myself. winpcap isn't to blame for such issues either. It's widely used by a lot of people (myself included), and we're not getting those BSODs. It's really AVG.

Posted

Just because a driver is malfunctioning doesn't mean that lspfix is going to find anything, as it only scans for errors in the winsock stack. You'd be better off considering Avira antivir, if you really want a recommendation.

As to learning how to do it, you first are going to need to understand the programming language(s) involved in what you're debugging (in the case of Windows, you need C and C++, and you may need some .net language and runtime knowledge as well), as well as a decent understanding of how the system works (otherwise, it's really hard to spot when it's not working). Debugging in and of itself is just running commands, but knowing what to do and when takes skill and experience (more of the latter than former, as well). I am not trying to dissuade you at all, so don't think this is a post to do so - I just want you to understand that it's not as easy as it looks.

If you are serious about learning, I would recommend learning to program (if you don't already) as a first step, preferably in C or C++. Also, you need to learn a bit more about the internals of Windows and how it works, so pick up Windows Internals 4th Edition by Mark Russinovich and David Solomon. Once you've gotten decent at writing your own apps (you'll pick up some debugging there, as you will find it sometimes necessary to do so to make your apps work), you're going to need to read a bit about some more advanced debugging techniques and tools as you go, so pick up Advanced Windows Debugging by Mario Hewardt and Daniel Pravat whilst you start debugging everything you can get your debugger into. And ultimately, practice, talking to others who do this well, and experience over time is what will ultimately give you what you need. Good luck, if you decide to travel down this road - anyone can write code, and anyone can be an admin, but to be able to do all 3 is something few can do, and something most people want to find. These are good skills to have if you plan to use them, but you'll find that it takes a few years (and then some) before you're good at all 3.

Posted

In addition to cluberti's usual most excellent recommendations, I'd like to add Tess' blog on MSDN which I've been following a while. Great resources, and great TechDays presentation too I must say. Mark Russinovich's blog also goes into that stuff sometimes.

I've been considering buying some of Dmitry Vostokov's books too, cheap, but no idea if they're any good. He has a pretty decent site too.

Posted

Dmitry has his Windows Internals cert, and I've enjoyed his posts over the years. I'd trust the book, although it's probably about as deep as Advanced Windows Debugging, so definitely not a good "starter" book either.

Posted

Thank you all for your help so far. I know several programming languages(Java,Ruby,Perl,etc, no C, C++, or C# though), it's just that Windows is not really my most comfortable environment, lol. I should start learning more :)

For reference, a lot of Googling lead me to believe that it's a problem with running Ares (Galaxy) or uTorrent, or at least that was the conclusion of a few other people who had similar problems. I'm going to see if nothing happens without running either for a week, and then possibly switch software to see what works.

Thanks!

Posted
it's a problem with running Ares (Galaxy) or uTorrent

User mode apps like this can't actually cause BSODs. The thing is that they generate a fair amount of traffic, which only exacerbates issues caused by poor network-related drivers (such as AVG's).

that was the conclusion of a few other people who had similar problems

Most of such conclusions I've seen are often completely wrong, as most end users are just not capable of diagnosing such issues by themselves. It just seems to me like they managed to get less BSODs caused by network-related drivers simply by minimizing network traffic (much like you're less prone to flat tires when you leave the car in the driveway -- not that it actually solved anything). Correlation is not causation.

cluberti really knows what he's saying. His crash dump analysis is certainly worth a LOT more than what a couple of average end-users think is the issue (not much more than plain old guessing, and not always an informed guess even). Besides, IRQL_NOT_LESS_OR_EQUAL are most frequently caused by poor drivers (or otherwise broken hardware). And the crash dump shows avg's driver (avgtdix.sys -- described as "AVG Network connection watcher") in the call stack right before it bugchecked...

On a side note, looks like Windows Internals 5th ed should be out in about 3 months!

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...