0

I was working on my computer for a few hours (Only had Remote Desktop and Firefox up, no heavy resource usage) when it randomly BSOD'd with DRIVER_IRQL_NOT_LESS_OR_EQUAL and a dll I've never heard of called xuicfs.sys . I took down the information, restarted, and tried to do some research. 10 minutes later, it BSOD'd again. And not 5 minutes after the 3rd reboot, it BSOD'd again. Same for the 4th one. For the 5th time I got frustrated and booted into safe mode and copied all the dump files (look below) and changed the dump state to full memory dump. However the 6th boot hasn't BSOD'd (yet). EDIT: BSOD'd again with same error when trying to update Windows Update.

The original BSOD information:

DRIVER_IRQL_NOT_LESS_OR_EQUAL 
0x000000D1 (0xBA5F2000, 0x00000002, 0x00000000, 0xB9EAE747)
xuicfs.sys - Address B9eae747 base at B9eaa000, Datestamp 4ce807c

3rd one:

DRIVER_IRQL_NOT_LESS_OR_EQUAL
0x000000D1 (0xBA63C000, 0x00000002, 0x00000000, 0xB9EAE747)
xuicfs.sys - Address B9EAE747 base at B9EAA000, DateStamp 4ce80a7c

Naturally, I wondered what "xuicfs.sys" was. However, a Google Search worried me when there wasn't any hits. Not surprisingly, the file exists in c:\WINDOWS\system32\drivers . McAfee doesn't think its a virus.

Whats strange is that this computer actually isn't mine, its a friends that I've been fixing over the past week. It had a really strange error where the CD and HD bootloaders got corrupted (yes, CD booting doesn't work), and apparently had a blue screen the last time it was working. I was able to fix the HD bootloader by putting the hard drive in another computer, booting up to the XP recovery console, running fixmbr and fixboot, putting back, booting into Windows, and running a chkdsk on the next restart. Really strange, but it worked.

Since the fix the computer has been used for a total of 12-18 hours without failing. I have installed no software since then, only the Lastpass addon for Firefox.

What worries me is that when I went to copy the dump files there were 140 dump files dating back to June 2008. I have no idea though if they are connected as I don't even think the event viewer keeps track of logs going that far back.

After some Googling I found an online Dump analysis tool. Here's an analysis of the 4th BSOD

Crash Dump Analysis provided by OSR Open Systems Resources, Inc. (http://www.osr.com)
Online Crash Dump Analysis Service
See http://www.osronline.com for more information
Windows XP Kernel Version 2600 (Service Pack 2) UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 2600.xpsp_sp2_qfe.090804-1435
Machine Name:
Kernel base = 0x804d7000 PsLoadedModuleList = 0x80553dc0
Debug session time: Sun Dec  5 20:25:32.184 2010 (UTC - 5:00)
System Uptime: 0 days 0:01:47.765
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: ba628000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: b9eae747, address which referenced memory

Debugging Details:
------------------


READ_ADDRESS:  ba628000 

CURRENT_IRQL:  2

FAULTING_IP: 
xuicfs+4747
b9eae747 0fb618          movzx   ebx,byte ptr [eax]

CUSTOMER_CRASH_COUNT:  4

DEFAULT_BUCKET_ID:  COMMON_SYSTEM_FAULT

BUGCHECK_STR:  0xD1

PROCESS_NAME:  Idle

LAST_CONTROL_TRANSFER:  from b9edb79d to b9eae747

STACK_TEXT:  
WARNING: Stack unwind information not available. Following frames may be wrong.
805497b8 b9edb79d ba628000 ba627fff 887725a3 xuicfs+0x4747
80549800 b51f78ff 889c1738 89113bf8 89113bfc xuicfs+0x3179d
80549818 b51fc4bd 887724e8 00000000 00002000 tcpip!TCPDataRequestComplete+0xa6
80549854 b51fc570 00000000 00000002 00000000 tcpip!CompleteRcvs+0xf1
80549878 b51f3a08 00000002 00000002 805498a4 tcpip!ProcessPerCpuTCBDelayQ+0x6b
805498ac b51f394f 00000002 b51f3900 b51f33d6 tcpip!ProcessTCBDelayQ+0xc4
805498b8 b51f33d6 00000000 89fb0688 b51f37f2 tcpip!TCPRcvComplete+0x20
805498c4 b51f37f2 b9da4d40 891a7008 b83b9b40 tcpip!IPRcvComplete+0x21
805498c8 b9da4d40 891a7008 b83b9b40 891fe780 tcpip!ARPRcvComplete+0x5
80549918 b83b401d 00441748 8924a668 00000001 NDIS!ethFilterDprIndicateReceivePacket+0x5a4
8054992c b83b41b4 89fb0688 8924a668 00000001 psched!PsFlushReceiveQueue+0x15
80549950 b83b45f9 891fe788 00000000 89fb0688 psched!PsEnqueueReceivePacket+0xda
80549968 b9da4d40 891fe780 8053c890 89f01000 psched!ClReceiveComplete+0x13
805499b8 b8dca2e4 00441748 89f015d4 00000001 NDIS!ethFilterDprIndicateReceivePacket+0x5a4
00000000 00000000 00000000 00000000 00000000 NVENETFD+0x32e4


STACK_COMMAND:  kb

FOLLOWUP_IP: 
xuicfs+4747
b9eae747 0fb618          movzx   ebx,byte ptr [eax]

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  xuicfs+4747

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: xuicfs

IMAGE_NAME:  xuicfs.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4ce80a7c

FAILURE_BUCKET_ID:  0xD1_xuicfs+4747

BUCKET_ID:  0xD1_xuicfs+4747

Followup: MachineOwner
---------

----- 32 bit Kernel Mini Dump Analysis

DUMP_HEADER32:
MajorVersion        0000000f
MinorVersion        00000a28
KdSecondaryVersion  00000000
DirectoryTableBase  003b2000
PfnDataBase         81600000
PsLoadedModuleList  80553dc0
PsActiveProcessHead 80559f58
MachineImageType    0000014c
NumberProcessors    00000001
BugCheckCode        100000d1
BugCheckParameter1  ba628000
BugCheckParameter2  00000002
BugCheckParameter3  00000000
BugCheckParameter4  b9eae747
PaeEnabled          00000001
KdDebuggerDataBlock 805458e0
SecondaryDataState  00000000
ProductType         00000001
SuiteMask           00000310
MiniDumpFields      00000dff 

TRIAGE_DUMP32:
ServicePackBuild      00000200 
SizeOfDump            00010000 
ValidOffset           0000fffc 
ContextOffset         00000320 
ExceptionOffset       000007d0 
MmOffset              00001068 
UnloadedDriversOffset 000010a0 
PrcbOffset            00001878 
ProcessOffset         000024c8 
ThreadOffset          00002728 
CallStackOffset       00002980 
SizeOfCallStack       000005bc 
DriverListOffset      000031d0 
DriverCount           00000076 
StringPoolOffset      000054d8 
StringPoolSize        00001048 
BrokenDriverOffset    00000000 
TriageOptions         00000041 
TopOfStack            80549744 
DebuggerDataOffset    00002f40 
DebuggerDataSize      00000290 
DataBlocksOffset      00006520 
DataBlocksCount       00000004 
  b9eae000 - b9eaefff at offset 00006560
  80549000 - 80549fff at offset 00007560
  ba627000 - ba627fff at offset 00008560
  ba626000 - ba626fff at offset 00009560
  Max offset a560, baa0 from end of file

I am currently trying to run an update to SP3 in hopes that it might fix the problem. Later I'm going to run Memtest86+ off of a flash drive just in case there is a rare bad RAM chip. Even though I ran a very vigorous chkdsk a few days ago, in the morning I'll run it again. EDIT: BSOD when running update. Already did a vigorous chkdsk (found nothing). Currently running Memtest

Computer specs:

  • OS: Windows XP SP2 (!)
  • Box: Dell Inspiron 531
  • Processor: AMD Sempron LE-1300 2.31 GHz
  • RAM: 1.93 GB
  • Antivirus: McAfee (*shutters)

For my question here: What else could be the problem? Usually BSOD's are the result of change, but nothing has changed in the setup or programs. I've never really seen a constant stream of BSOD's like this. Am I missing something? Is there more information I need to provide?

With as many problems as there was with the computer before and the trashed state of the programs (AOL, enough said), I am open to a reformat but that's a bit of a nuclear option in this case.

Any suggestions?

Improve this question

4 Answers 4

Reset to default
1

Start -> Run (or search on vista) -> devmgmt.msc

Click View, Show Hidden Devices.

Expand the "Non Plug n Play drivers" section.

Do you see anything corresponding to xuicfs? Anything with a yellow exclamation mark, or otherwise really odd looking?

Improve this answer
4
  • Hmm, forgot about showing non present devices in device manager. Under "Non-Plug and Play Drivers" there is a driver called xuicfs. Just for some testing I disabled but now it won't boot into Windows again... Currently trying to fix it
    – TheLQ
    Dec 6, 2010 at 21:39
  • Try uninstalling it, if you can get back into Windows/Safe mode. If it literally comes up with no pertinent results on Google, it's probably not a good thing. Are you getting the same error now as before?
    – geodave
    Dec 6, 2010 at 21:44
  • Tried Safe mode and Safe mode with command line, both freeze when trying to load some drivers. So I've now just broken this machine... Anyway to re-enable it either through a separate OS or through some other debug function of Windows? I have an Ubuntu disk and Windows XP Home reinstall disk that has the recovery console
    – TheLQ
    Dec 6, 2010 at 21:56
  • Trying "Last Known Good Configuration" could be helpful, if you haven't already. Beyond that, put in the XP Home disc, boot into the recovery console, and use the "enable" command to re-enable the driver. Type "enable xuicfs" and note the existing value. Then type something like "enable xuicfs SERVICE_SYSTEM_START" or "SERVICE_BOOT_START" and see if that lets you boot up. That should reverse the action you took in the device manager.
    – geodave
    Dec 7, 2010 at 5:47
0

I have had occasions like that where Windows is trying to talk to a peripheral through the driver and because the peripheral is damaged, causes a BSOD. From your other experiences with the computer I would say that there may be some piece of hardware is dying/dead in the computer, or the hard drive might be corrupted causing a BSOD when it is accessing the driver.

Memtest86+ is a good idea to try and maybe the SMART tools on an Ubuntu CD.

Improve this answer
2
  • Ran Memtest overnight, didn't find anything. I pulled up Ubuntu 10.10, where are the smart tools?
    – TheLQ
    Dec 6, 2010 at 21:18
  • Under System -> Administration -> Disk Manager then click on the drive in question, you will see the ability to check the SMART status for a drive or do a scan.
    – Ptier
    Dec 6, 2010 at 22:22
0

chkdsk most likely fixed the issue, corruption of files or file system is a main cause of BSODs in XP.

I run chkdsk /f once a month or so as preventative maintenance.

Just out of curiosity do a properties on that xuicfs file, see what the details tab says, might give a clue what it belongs to.

Improve this answer
4
  • I went ahead and ran the chkdsk. Didn't report any errors. The thing is though is that I ran a full chkdsk 3 days ago (The option that searches for bad sectors and gives you 5 stages). If your chkdsk idea is true, then this shouldn't of happened. With the file info, I don't think it will give any useful information but I'll check in the morning
    – TheLQ
    Dec 6, 2010 at 3:27
  • Did chkdsk /r find any bad sectors?
    – Moab
    Dec 6, 2010 at 4:59
  • Ran it, didn't find anything. Now I'm really stumped since I found out it BSOD's at the login screen...
    – TheLQ
    Dec 6, 2010 at 21:17
  • Is it the same file causing the bsod?
    – Moab
    Dec 7, 2010 at 0:28
0

Completely forgot about this question...

Some time later I got a new SATA hard drive, replaced the old one, installed Fedora Linux, and its been working beautifully ever since. This means that there are several possible reasons why this all happened

  • Something was VERY wrong with the old drive - Controller, physical defect, corrupt sectors, I don't know. The reason I suspect the hard drive was because the problems successively got worse, which is a sign of a failing hard drive. What's really strange though is that none of the hard drive checking utilities (fsck in Linux, chkdsk in Windows, SMART) revealed anything.
  • Bad component - This could be anything else that Windows was trying to use and that Linux hasn't touched or used as much. I have no idea.
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .