Link to home
Start Free TrialLog in
Avatar of jonathanv_00
jonathanv_00

asked on

Need help deciphering Stop message!

Preface: The MS Knowledge Base can be so annoying sometimes -- I asked about a stop message (see below), poked around, did some other stuff, and wanted to go back to an article I'd seen, so I searched on the same stop message -- and got a different set of responses . . .

Problem: I'm trying to decide whether or not applying SP6a to a server that's giving us problems will help.  Basically, it randomly crashes with the following Stop message:

Stop: 0x0000000A (0x.00000004, 0x00000012, 0x00000000, 0x801EAF7A)
IRQL_NOT_LESS_OR_EQUAL ***
Address 801eaf7a has been based at 80le3000_aic78xx.sys
CPUID: Genuine Intel 65.2 irql:1fDPC Sysver 0xf0000565
The next six DLL Base/file lines read:  ntoskernel.exe, atapi.sys, aic78xx.sys, hal.dll, scsiport.sys, and aic7802.sys, plus hex codes.

At first, I thought that all of this indicated a problem with the SCSI adapter driver (aic78xx.sys, right?); but on my second go-round with the KB, I see that the IRQL line indicates that it may have something to do with "a Winsock application that uses the sendto() function repeatedly in succession."

So . . . any help on decoding this message?  Which part is more relevant?  Will SP6a help? The KB articles suggest that SP4 fixed those errors, but I have applied that thing so many times, it's not funny anymore.

SP6a also seems to fix printing spool errors, which one client machine has been having problems with.

So, here are my questions:  (1) We have three domains, linked by an ATMP WAN over DSL.  Is it a good idea to apply SP6a to all domain controllers, or can I get away with just applying it to the one that's troublesome?  I'm sometimes leery of updating servers that are doing just fine.

(2) Will SP6a help?  Or should I just re-apply (again) SP4, and hope for the best?  I updated the Adaptec and video drivers last week, but then didn't re-apply SP4; crashes actually seem to be happening more frequently as a result. (three in one week, versus two in one week.) Thanks in advance.

Jonathan
ASKER CERTIFIED SOLUTION
Avatar of jhance
jhance

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of AdamWoodland
AdamWoodland

Well, unless there is a specific reason why not to go to the latest SP (i.e. program not working with it), I think that they should upgrade to the latest service pack.

[<-- Personal opinion and not necessay the answer to your problems :-) ]
I found this on it if it is any help


SYMPTOMS
When you run a program that makes a ScsiBusScan() call (for example, Disk Administrator), the following error message may be displayed on a blue screen:

STOP 0x0000000A (0x0000000C, 0x0000000A, 0x00000001, 0x801de690)
IRQL_NOT_LESS_OR_EQUAL
Address 801de690 has base at 801de000 - scsiport.sys
NOTE: The fourth parameter may vary from system to system, but is always based in Scsiport.sys.



CAUSE
The problem may occur if there are multiple programs issuing the IOCTL_SCSI_RESCAN_BUS I/O control at the same time. There is a race condition that can cause the same request to get issued twice.



RESOLUTION
A supported fix that corrects this problem is now available from Microsoft, but it has not been fully regression tested and should be applied only to systems experiencing this specific problem. If you are not severely affected by this specific problem, Microsoft recommends that you wait for the next Windows NT 4.0 service pack that contains this fix.

To resolve this problem immediately, contact Microsoft Product Support Services to obtain the fix. For a complete list of Microsoft Product Support Services phone numbers and information on support costs, please go to the following address on the World Wide Web:


http://www.microsoft.com/support/supportnet/overview/overview.asp

The English version of this fix should have the following file attributes or later:

   Date     Time    Size     File name      Platform
   --------------------------------------------------
   9/1/99   7:14p   35,504   Scsiport.sys   Intel
   9/1/99   7:13p   56,400   Scsiport.sys   Alpha





STATUS
Microsoft has confirmed this to be a problem in Windows NT 4.0.
Avatar of jonathanv_00

ASKER

Seems I say this every time . . . I love this place.  Thanks for the prompt responses.

pyleo -- Thanks, but I'd seen that KB article, and it doesn't seem to apply; scsiport.sys only appears after the first four lines (which MS suggests are the important part. I just included the second part for completeness.)  I thought I saw it in the stop code once, but not on any of the last few crashes, so I may be mistaken.

Adam -- thanks for the advice, but I'm of the firm belief that if a Windows system is more or less stable, don't touch it.  Especially since MS says that SP6a is a recommended update, not a "must-have."  (Funny how we trust them for some things, but not others!)

Finally, jhance -- I'm embarassed to ask, thinking I should know this, but how do I check for failing RAM?  I did a quick look at Tucows, and didn't come up with anything, although on another question here, someone suggested Check it Pro, Wincheckit, or QA/Plus.  I'll keep looking.  It's hard to wade through all of the info on SP6a to determine whether or not it would help, but none of the bugs seem to apply to my situation.  I guess I'm just surprised that something as simple as a driver update requires re-application of a SP. (I got the most recent drivers off of the appropriate websites, so I'm pretty sure they're OK.)  I also assume from your comment that it isn't really necessary to apply the same SP to all three servers?

Thanks for your help.  I'll keep checking this over the weekend for other comments, etc., and give yo a report back after I go to that office on Monday.  I'm almost hoping for bad RAM . . .
p.s. jhance -- I also wanted to say thanks for your first comment about what IRQL messages usually mean; I find that kind of stuff _very_ helpful.
-Are you 1000% sure of the Termination & IRQ conflicts with your 2940 u2w ?
Housenet -- Had to add that extra 0, there, didn't you?!  Good point, however.  I will check that; if the termination is slightly unseated, would that cause random (once every two months, then three times in one week) disconnections?  

Hm . . . I also just noticed in Devices that, in addition to the aic78xx (started/boot), I have another similar device  -- aic78u2 (not started/boot).  I think that's from when I tried to install the U2W driver (low voltage model?), instead of the regular 2940 UW.  IRQs and SCSI drives are two pieces of hardware with which I don't play well . . . Can I only check the IRQs from the BIOS setup when booting up, or is there some way to get to those in Control Panel?  Many thanks.
-What happened when you tried to load the other driver ? Try updating the driver from scsi in control panel (dangerous implications).
If I remember correctly, I put it on the drive and then had second thoughts.  So, I never actually loaded it in SCSI Adapters; I was about to do so, but then got cold feet, thinking that it was not quite the right driver (different name).  The way Adaptec has that "family" of drivers set up is kind of confusing.  

What are the "dangerous implications" of trying to update (Add?) the driver from SCSI Adapters in Control Panel?  I'm headed to that office tomorrow; I just tried to connect to it, and it looks like it's down again. I'll check back here tomorrow. . .

Thanks!
OK, here's the story:  I disabled the aic78u2 in Devices; it was in fact showing up in the first few lines after the stop codes on the blue screen (see above; "aic7802.sys" should read "aic78u2.sys" -- bad fax).

The %$*&@ thing crashed today while I was on it (writing an e-mail), so I got to actually see one of the screens. Nothing new appeared, so at least the problem is consistent.  

Housenet -- I opened up the machine and checked/reseated the cables, and I don't see any IRQ conflicts in the BIOS setup.  As I say, though, good suggestion.  But once again -- is there anywhere else to check IRQs other than BIOS setup?

And jhance -- how can I check for failing RAM? The problem now is that it will be hard to tell if any of this does any good. If it crashes tomorrow or next week, I'll know it didn't.  But last time we went two months between crashes.  Just have to hope, I guess.

Thanks again.  
jhance -- I'm willing to give you the points, but I would like to hear anything on how to check for failing RAM.  Thanks.
Hey, folks -- anyone still out there? I don't wanna just cancel this question . . .
jhance -- I'm going to give you the 200 points, because I did reapply the service pack (4), and don't like leaving questions open.  I suspect it may also have been the duplicate devices. In any case, thanks for comments!
(see above)