Jump to content

Normal mode booting OK but BSoD in safe mode


luweitest

Recommended Posts

13 hours ago, HarryTri said:

Sorry but I run chkdisk all my life (almost:whistle:) and all this stuff is absolutely normal (the bad sectors aren't so common but sometimes they exist too).

It must have been a tough life with an OS (or given set of programs) that constantly trash your NTFS. :(

No, it isn't "normal", it happens, but it shouldn't and surely it shouldn't happen often.

@luweitest

Good. :)

At least now there is (or should be) a "solid base".

Let's see what SFC comes out with.

jaclaz

Link to comment
Share on other sites


Minor inconsistencies of a drive happen from time to time (not very often), unused security descriptors are always present even if you run an NTFS system for just a day.:huh: Reallocated, pending or uncorrectable sectors are rare but they do still occur and usually are harmless (unless they increase from day to day which is a certain sign of disk failure, I had such a case myself).

Link to comment
Share on other sites

Minor inconsistencies of  file 0x9 is normal runing chkdsk. I run it today and still got them:
Cleaning up 28 unused index entries from index $SII of file 0x9.
Cleaning up 28 unused index entries from index $SDH of file 0x9.
Cleaning up 28 unused security descriptors.

I ran sfc /scannow for three times. It prompts for CD from time to time even if CD is there. At first I thought maybe the CD is wrong and click "ignore" once, thus I ran second time. After checking the eventlog and made some change, I rebooted and ran it third time to be sure no issue remains.

What sfc has done: It creates lots of old***.tmp file in C:\WINDOWS\system32\dllcache, which I think most are extracted from C:\WINDOWS\Driver Cache\i386\drivers.cab, then if the file is not there, restore its original name; if the file is there, delete the tmp file at next reboot. After copied 700+ files, 3 files were logged as event:

c:\program files\common files\microsoft shared\web server extensions\40\bin\2052\fpmmcsat.dll not copied to dllcache. (There's no such file in the folder, but there is one in system32\dllcache, I copied it back.)

c:\windows\system32\ati3duag.dll not copied to dllcache. (The file is not there, I find it in sp3.cab and extracted it back)

c:\windows\system32\msisip.dll has wrong signature and is restored from version 4.5.6001.22159 to 3.1.4001.5512 (This file is strange. I re-installed Windows Installer 4.5 (the installer file WindowsXP-KB942288-v3-x86.exe is signed) , checked msisip.dll and it's still unsigned. I think this is a MS bug),

fpmmcsat.dll and ati3duag.dll may be the files that got "lost" during WinDlg repair, but they seems no important (My video adapter is Intel965, not from ATI). And consequently, BSOD still occurs in safe mode, but with slightly different number:

0x0000007E (0xC0000005, 0xF76C0211, 0xF78E6700, 0xF78E63FC)

The previous message:

0x0000007E (0xC0000005, 0xF76E0211, 0xF78EA700, 0xF78EA3FC)

Edited by luweitest
Link to comment
Share on other sites

@luweitest

0xC0000005: STATUS_ACCESS_VIOLATION is definitely related to system memory. Try removing RAM modules, cleaning RAM pins, re-inserting in different motherboard slots. Try replacing at least one (SO-)DIMM module if possible. Try booting the system with only one (SO-)DIMM inserted. I think the reason of this BSOD will come to light sooner or later.;)

P.S. And try using discrete video card instead of integrated one (where is it, BTW? Thinkpad should have one, AFAIK). I was confused with ati3duag.dll file presence. Was there a video card from ATI installed once? Perhaps this is the reason. Try removing and cleaning possible ATI leftovers from system.

Edited by Bersaglio
add, fix
Link to comment
Share on other sites

Well, if you like to call that "normal" it's fine, but still it isn't "normal".

Is it not that you are in one of the conditions seen here? :dubbio:

https://web.archive.org/web/20090331144811/http://support.microsoft.com/kb/831374

Running vrfydsk could be a good idea:

https://www.microsoft.com/en-us/download/details.aspx?id=17657

jaclaz

 

Link to comment
Share on other sites

On 2/28/2019 at 3:30 PM, Bersaglio said:

@luweitest

0xC0000005: STATUS_ACCESS_VIOLATION is definitely related to system memory. Try removing RAM modules, cleaning RAM pins, re-inserting in different motherboard slots. Try replacing at least one (SO-)DIMM module if possible. Try booting the system with only one (SO-)DIMM inserted. I think the reason of this BSOD will come to light sooner or later.;)

P.S. And try using discrete video card instead of integrated one (where is it, BTW? Thinkpad should have one, AFAIK). I was confused with ati3duag.dll file presence. Was there a video card from ATI installed once? Perhaps this is the reason. Try removing and cleaning possible ATI leftovers from system.

I did as you said: two DIMM module, 1G each,

original position A, B:

0x0000007E (0xC0000005, 0xF76C0211, 0xF78E6700, 0xF78E63FC)

position A, null:

0x0000007E (0xC0000005, 0xF7884211, 0xF7BFE700, 0xF7BFE3FC)

position null, B (slot warning during BIOS start, but can continue):

0x0000007E (0xC0000005, 0xF7934211, 0xF7CAE700, 0xF7CAE3FC)

position B, null:

0x0000007E (0xC0000005, 0xF7884211, 0xF7BFE700, 0xF7BFE3FC)

position B, A:

0x0000007E (0xC0000005, 0xF76E0211, 0xF78EA700, 0xF78EA3FC)

What can those changing numbers reveal?

And I ran Memtest86+ for 55 minutes, all passed without error.

ATI device is never installed. The notebook's hardware is fixed. ati3duag.dll is not there at first, it is sfc.exe that complains about it and I find it in sp3.cab, extract it out to satisfy sfc.

 

Edited by luweitest
Link to comment
Share on other sites

On 2/28/2019 at 6:44 PM, jaclaz said:

Well, if you like to call that "normal" it's fine, but still it isn't "normal".

Is it not that you are in one of the conditions seen here? :dubbio:

https://web.archive.org/web/20090331144811/http://support.microsoft.com/kb/831374

Running vrfydsk could be a good idea:

https://www.microsoft.com/en-us/download/details.aspx?id=17657

jaclaz

 

Should not be related to kb831374, which states "This problem occurs because the Chkdsk utility may not find references to all the security IDs if the master file table is larger than 4 gigabytes (GB) or if there are more than 4,194,303 files on the volume."

My C: have 100,738 files, $MFT is 138MB.

vrfydsk could not run because "Shadow copy creation failed". I think maybe because I stopped Volume shadow copy service, and there's not enough space to create a copy of C drive.

Link to comment
Share on other sites

7 hours ago, luweitest said:

What can those changing numbers reveal?

Registers data, maybe memory addresses in this case. Try uninstalling Your VGA drivers (Intel 965) and restoring plain VGA driver. Then try booting in Safe mode again.

Link to comment
Share on other sites

Instead of uninstalling video driver, I add "/BASEVIDEO" switch to boot.ini, which will make windows to use the standard VGA display driver. Still got stop message:

0x0000007E (0xC0000005, 0xF76E0211, 0xF78EA700, 0xF78EA3FC)

Link to comment
Share on other sites

Well, Your problem is caused by some corrupted/unsigned driver during its loading process in safe mode. There may be many options: antivirus, some third-party app which can sometimes cause problems (like Nokia PC Suite) or... I don't know how to localize the cause and alas, I have no other ideas sadly...:unsure:

Link to comment
Share on other sites

On 3/2/2019 at 8:34 AM, luweitest said:

What can those changing numbers reveal?

And I ran Memtest86+ for 55 minutes, all passed without error.

It's no the RAM itself, something before the RAM.
E,g broken capacitors or power supply. At a old machine, capacitors may dry out, without a bulking head.
Ignore the error so far, replace the hardware in future.

Link to comment
Share on other sites

On 3/2/2019 at 2:34 AM, luweitest said:

I did as you said: two DIMM module, 1G each,

original position A, B:

0x0000007E (0xC0000005, 0xF76C0211, 0xF78E6700, 0xF78E63FC)

position A, null:

0x0000007E (0xC0000005, 0xF7884211, 0xF7BFE700, 0xF7BFE3FC)

position null, B (slot warning during BIOS start, but can continue):

0x0000007E (0xC0000005, 0xF7934211, 0xF7CAE700, 0xF7CAE3FC)

position B, null:

0x0000007E (0xC0000005, 0xF7884211, 0xF7BFE700, 0xF7BFE3FC)

position B, A:

0x0000007E (0xC0000005, 0xF76E0211, 0xF78EA700, 0xF78EA3FC)

What can those changing numbers reveal?

https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x7e--system-thread-exception-not-handled

Link to comment
Share on other sites

On Πέμπτη, 28 Φεβρουαρίου 2019 at 12:44 PM, jaclaz said:

Well, if you like to call that "normal" it's fine, but still it isn't "normal".

By the way to see the unused security descriptors reported you must use chkdsk with the /v switch (we always talk about NTFS file system of course).

Link to comment
Share on other sites

Thanks for all your input. This trivial (maybe) bug seems unexpectedly deep. As now the direction leads to driver issue and profound developer knowledge,  I think I have digged enough as a layman. Thinkpad X61's drivers have stopped updating for years, so even if I located the buggy driver, I can do nothing about it. Seems I have to live with this. Anyway I don't use safe mode: I created two usb boot disk in case of emergency.

Link to comment
Share on other sites

Rather late in the day to this, and I'm sure this has probably already been tried, but if I had this issue I would try uninstalling everything in Device Manager, ignoring the reboot notices of course, and then see if the machine will boot in Safe Mode.
If it does, then it must be a driver problem and then it's just (ha-ha!) a matter or narrowing down which one it is.
When you reboot normally the OS should put all the devices back again as you haven't actually removed the driver software from the machine (there's an option to do that on uninstall on later versions of Windows, but not on XP). It may actually put them back differently, which might also affect the problem.
:)
 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

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