XP SP2 System taking Minidumps. Unable to analyze

**Iphone** · 17-Apr-2007, 06:16 AM

My client has XP SP2 on a ACER 2.8GHZ Dual Core. Chipset Intel(R) 946GZ Express Chipset Family (224 MB). 1GB of Memory. Since the first day we got this machine and installed the clients applications it started re-booting.

Many MINIDUMPS have been created. I swapped out the memory and it still dies. Put the Image of that machine on an entirely different machine and it still dies. Now I'm back to the original machine at it is dying anywhere from 2-7 times a day.

I downloaded Windbg:6.6.0007.5 and then the Symbols for XP SP2, pointed Windbg to them and all I get is...
"unable to load image ntoskrnl.exe symbols could not be loaded". These minidumps are giving me nothing to go on.

I have the output of a Full Everest run in text format if that would be helpful and of course all of these Minidumps.

Today I went to the site and changed the dump type to "Complete versus Mini"

I need someone to help me. I have over 20 of these Minidumps that mean nothing to me.
I either need someone to analyze them for me and/or tell me what I'm doing wrong in attempting to debug them.

My client is using this machine as a Fileserver and when it crashed it takes their small business down with them. That is why this is urgent

**Iphone** · 17-Apr-2007, 06:16 AM

Most recent down....

OsaFsLoc.sys
OsaFsLoc.sys
OsaFsLoc.sys
OsaFsLoc.sys

Ok, we see a pattern here.....

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: e3be6000, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 805390f3, If non-zero, the instruction address which referenced the bad memory address.
Arg4: 00000001, (reserved)

The Last Control Transfer, shows the first mem address being OsaFsLoc.sys, making a call to NToskrnl.exe, which is when it is throwing up the BSOD.....
LAST_CONTROL_TRANSFER: from f79c4d73 to 805390f3

In your debugger, several basic commands...

!analyze -v
then
lmv

17-Apr-2007, 06:16 AM	#1 (permalink)
Iphone Fixed Error! Posts: 4,202 Join Date: Mar 2007 Rep Power: 6 IM:	XP SP2 System taking Minidumps. Unable to analyze My client has XP SP2 on a ACER 2.8GHZ Dual Core. Chipset Intel(R) 946GZ Express Chipset Family (224 MB). 1GB of Memory. Since the first day we got this machine and installed the clients applications it started re-booting. Many MINIDUMPS have been created. I swapped out the memory and it still dies. Put the Image of that machine on an entirely different machine and it still dies. Now I'm back to the original machine at it is dying anywhere from 2-7 times a day. I downloaded Windbg:6.6.0007.5 and then the Symbols for XP SP2, pointed Windbg to them and all I get is... "unable to load image ntoskrnl.exe symbols could not be loaded". These minidumps are giving me nothing to go on. I have the output of a Full Everest run in text format if that would be helpful and of course all of these Minidumps. Today I went to the site and changed the dump type to "Complete versus Mini" I need someone to help me. I have over 20 of these Minidumps that mean nothing to me. I either need someone to analyze them for me and/or tell me what I'm doing wrong in attempting to debug them. My client is using this machine as a Fileserver and when it crashed it takes their small business down with them. That is why this is urgent

17-Apr-2007, 06:16 AM	#2 (permalink)
Iphone Fixed Error! Posts: 4,202 Join Date: Mar 2007 Rep Power: 6 IM:	Re: XP SP2 System taking Minidumps. Unable to analyze Most recent down.... OsaFsLoc.sys OsaFsLoc.sys OsaFsLoc.sys OsaFsLoc.sys Ok, we see a pattern here..... PAGE_FAULT_IN_NONPAGED_AREA (50) Invalid system memory was referenced. This cannot be protected by try-except, it must be protected by a Probe. Typically the address is just plain bad or it is pointing at freed memory. Arguments: Arg1: e3be6000, memory referenced. Arg2: 00000000, value 0 = read operation, 1 = write operation. Arg3: 805390f3, If non-zero, the instruction address which referenced the bad memory address. Arg4: 00000001, (reserved) The Last Control Transfer, shows the first mem address being OsaFsLoc.sys, making a call to NToskrnl.exe, which is when it is throwing up the BSOD..... LAST_CONTROL_TRANSFER: from f79c4d73 to 805390f3 In your debugger, several basic commands... !analyze -v then lmv

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)