Sysinternals Homepage
Forum Home Forum Home > Windows Discussions > Troubleshooting
  New Posts New Posts RSS Feed: MiSystemVaType memory?
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

MiSystemVaType memory?

 Post Reply Post Reply Page  123 4>
Author
Message Reverse Sort Order
jhoffa View Drop Down
Groupie
Groupie


Joined: 03 March 2008
Online Status: Offline
Posts: 47
Post Options Post Options   Quote jhoffa Quote  Post ReplyReply Direct Link To This Post Topic: MiSystemVaType memory?
    Posted: 13 May 2008 at 4:18pm
Yep issue seems to be completely resolved now. Unfortunately I was never able to provide any interesting results from driver verifier, since the service pack (that took place around my last relevant comment) apparently took care of the issue. By the time I had run the tool, everything seemed to check out just fine. (heh to be honest this whole time I was actually waiting for the crash to reappear for more testing).
 
Just recently I noticed that there was a specific patch targeting this issue, so I figured I'd share it as an FYI and also in case anyone else affected by this happened to run by this post.
Back to Top
molotov View Drop Down
Moderator Group
Moderator Group
Avatar

Joined: 04 October 2006
Online Status: Offline
Posts: 17492
Post Options Post Options   Quote molotov Quote  Post ReplyReply Direct Link To This Post Posted: 10 May 2008 at 7:12pm
Interesting - I take it that after applying the fix your problems went away?
Daily affirmation:
net helpmsg 4006
Back to Top
jhoffa View Drop Down
Groupie
Groupie


Joined: 03 March 2008
Online Status: Offline
Posts: 47
Post Options Post Options   Quote jhoffa Quote  Post ReplyReply Direct Link To This Post Posted: 10 May 2008 at 7:07pm
There's a fix for this now on windows update available under optional updates. NVIDIA Corporation driver update for NVIDIA nForce Serial ATA Controller
Back to Top
molotov View Drop Down
Moderator Group
Moderator Group
Avatar

Joined: 04 October 2006
Online Status: Offline
Posts: 17492
Post Options Post Options   Quote molotov Quote  Post ReplyReply Direct Link To This Post Posted: 11 April 2008 at 5:53pm
If NTKRNLPA.EXE verifies with Sigcheck, the disk file is probably OK...
 
as opposed to a straight "bad driver" crash
The last several BSODs (the ones for which there is more than a minidump available) have pointed to memory corruption.
 
Without Verifier, the bugcheck can certainly happen much later than the actual memory corruption occurred.  That's why bugchecks caused by memory corruption can be hard to diagnose.  Verifier can enforce / institute additional "checks" to cause a bugcheck to happen at the point that memory gets corrupted - this makes it easier to figure out when the corruption happened, and who did it.
 
I'm afraid I don't see much relevance between your situation, and the referenced KB article (IRQL_NOT_LESS_OR_EQUAL != PAGE_FAULT_IN_NONPAGED_AREA)...
Daily affirmation:
net helpmsg 4006
Back to Top
jhoffa View Drop Down
Groupie
Groupie


Joined: 03 March 2008
Online Status: Offline
Posts: 47
Post Options Post Options   Quote jhoffa Quote  Post ReplyReply Direct Link To This Post Posted: 11 April 2008 at 4:49pm

Just a quick update. Sorry I haven't replied for awhile but there's been nothing to report (this also coupled with a thermostat meltdown in our data center this week kept me from doing more testing at home). I applied more patches (security hot fixes and a mb nic update i think[?]) a few days ago and no crash since. I'm quite sure that these crashes will reappear eventually though.

 

I still think this has something to do with ntkrnlpa.exe being modified or corrupted or at least some related kernel mode interruption as opposed to a straight "bad driver" crash. Whatever it is seems to be triggered by some event(s) (razer driver crash - not IRQL which started this whole mess & a video driver crash ended my 1.5 month period of freedom). This crash has been incredibly consistent with the exception of my reapplication of an earlier patch (1.5 months of no crashes) in an attempt to "fix" ntkrnlpa.exe as well as this most recent patch (3 days now[?]). I'm not quite sure how it could be explained otherwise.

 

 [update] Interesting. Just as I was typing this I ran across a brand new Microsoft article while searching for information on how exactly ntkrnpla.exe works and how to properly update it:

 

http://support.microsoft.com/kb/556066

 

Why this happens?
 
The file system filter driver of anti-virus keeps the data of its own in the Pagefile area or hard-coded memory. Other Windows processes (specially NTKRNLPA.exe) keep locking this page area when different I/O Operations occur. For example, one application or service is trying to access a file on drive D:\, the Antivirus file system filter driver invokes itself and checks the file (integrity, suspicious file etc) before it can allow application/service to access the file. Since the File System driver is a TSR program (Terminate and Stay Resident), it has to keep its non-volatile data in RAM or pagefile memory area. It retrieves these data at the time of performing I/O Operation (performing an operation when application/service tries to access the file). If this data is not found or not available or locked by other processes then Windows will throw a STOP error message. Okay..you may ask why Windows throws STOP error message, it can also log an event in System log instead of shutting down the system? It doesn't because any the change occurred in Kernel Mode processes/services always result in system crash. The crashed Kernel Mode processes need to re-initialise itself in order to make itself alive back in the system and this is only possible (only for Kernel Mode processes) when whole system is rebooted (this is as per Windows kernel architecture - first Windows Kerenel mode processes initialise and then User Mode processes. Please note - in Unix,  this is not the case as Linux/Unix Kernel has been separated from processes or third party services. You can always use INIT or other commands to re-initialise processes). Kernel mode processes always run using Realtime Priority that means they can fight with each other when a conflict raises between functions executed by them.

 

PS- I don't think the above is my issue, but it sounds like it could be analogous to what’s happening on my machine. Going to see if I can find out more about that timer.

Back to Top
molotov View Drop Down
Moderator Group
Moderator Group
Avatar

Joined: 04 October 2006
Online Status: Offline
Posts: 17492
Post Options Post Options   Quote molotov Quote  Post ReplyReply Direct Link To This Post Posted: 05 April 2008 at 7:16pm
report back from Problem Reports and Solutions
Hmm, interesting.  It's a known issue, with no fix (at least according to  Problem Reports and Solutions).
 
But I find it odd that PRS / OCA only seems to get minidumps, and all the minidumps you provided were rather... sparse... on information (at least, the info in them did not suggest memory corruption).  The (latest) kernel / complete dumps point to memory corruption.  Would be nice to know how OCA comes to its conclusions, but I would suppose it sees a lot of BSODs, so...  Still, perhaps it is worth pursuing the Verifier.
 
The referenced KB article about Norton lists XP and Server 2003 as affected, but not Vista.  Not sure if that's just an omission, or if Vista might not be affected in the same fashion.
 
Some more info about the Verifier:
Daily affirmation:
net helpmsg 4006
Back to Top
jhoffa View Drop Down
Groupie
Groupie


Joined: 03 March 2008
Online Status: Offline
Posts: 47
Post Options Post Options   Quote jhoffa Quote  Post ReplyReply Direct Link To This Post Posted: 05 April 2008 at 4:15pm
Problem caused by NVIDIA nForce(TM) SATA Driver is a report back from Problem Reports and Solutions. It states, "This problem was caused by NVIDIA nForce(TM) SATA Driver, which was created by NVIDIA Corporation. Currently, there is no solution for the problem that you reported."
 
What exactly should I look for with the verifier tool? Never used this before and seems like there is quite a bit you can do with it. I can only get 15% coverage with my currently physical memory when running all drivers.
 
Well I learned something new today. Driver verifier doesn't play nice with Norton. http://support.microsoft.com/kb/325672
Doesn't seem to be a bug for Norton, just thought you might be interested as an FYI.
 
DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught.  This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA will
be among the most commonly seen crashes.
        Parameter 1 = 0x1000 .. 0x1020 - deadlock verifier error codes.
               Typically the code is 0x1001 (deadlock detected) and you can
               issue a '!deadlock' KD command to get more information.
Arguments:
Arg1: 0000003c, ObReferenceObjectByHandle is being called with a bad handle.
Arg2: 000004b4, bad handle passed in,
Arg3: 83256518, object type,
Arg4: 00000000, 0.
Back to Top
molotov View Drop Down
Moderator Group
Moderator Group
Avatar

Joined: 04 October 2006
Online Status: Offline
Posts: 17492
Post Options Post Options   Quote molotov Quote  Post ReplyReply Direct Link To This Post Posted: 05 April 2008 at 2:46pm
Problem caused by NVIDIA nForce(TM) SATA Driver
Where do you get that from?  I see BUCKET_ID:  MEMORY_CORRUPTION_LARGE, just like the previous kernel dump (and possibly the complete dump, which I'm still downloading thanks to RapidShare's throttling...).
 
Looks like it's time to whip out the Driver Verifier...
 
Daily affirmation:
net helpmsg 4006
Back to Top
jhoffa View Drop Down
Groupie
Groupie


Joined: 03 March 2008
Online Status: Offline
Posts: 47
Post Options Post Options   Quote jhoffa Quote  Post ReplyReply Direct Link To This Post Posted: 05 April 2008 at 1:07pm

Todays seems similar to the last crash. Problem caused by NVIDIA nForce(TM) SATA Driver. Same faulting IP different read address/trap frame. I just removed LCDmon.exe and Daemon as well to see if I get any result.

2: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
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 a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 01f3a3bc, memory referenced
Arg2: 0000001b, IRQL
Arg3: 00000000, bitfield :
 bit 0 : value 0 = read operation, 1 = write operation
 bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 81ef4865, address which referenced memory

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


PEB is paged out (Peb.Ldr = 7ffd400c).  Type ".hh dbgerr001" for details

PEB is paged out (Peb.Ldr = 7ffd400c).  Type ".hh dbgerr001" for details

READ_ADDRESS:  01f3a3bc

CURRENT_IRQL:  1b

FAULTING_IP:
nt!KiInsertTimerTable+42
81ef4865 8b5ffc          mov     ebx,dword ptr [edi-4]

DEFAULT_BUCKET_ID:  CODE_CORRUPTION

BUGCHECK_STR:  0xA

PROCESS_NAME:  LCDMon.exe

TRAP_FRAME:  a428dbfc -- (.trap 0xffffffffa428dbfc)
ErrCode = 00000000
eax=81f3a3c0 ebx=895145e0 ecx=abe2c528 edx=7dca9ee0 esi=81f3a3c0 edi=01f3a3c0
eip=81ef4865 esp=a428dc70 ebp=a428dc90 iopl=0         ov up ei ng nz na pe cy
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010a87
nt!KiInsertTimerTable+0x42:
81ef4865 8b5ffc          mov     ebx,dword ptr [edi-4] ds:0023:01f3a3bc=????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from 81ef4865 to 81e96d84

STACK_TEXT: 
a428dbfc 81ef4865 badb0d00 7dca9ee0 00000002 nt!KiTrap0E+0x2ac
a428dc90 81e90ccb abe2c528 00000184 00000000 nt!KiInsertTimerTable+0x42
a428dce8 82085351 abea0830 00000006 81e6b701 nt!KeWaitForSingleObject+0x465
a428dd50 81e93a7a 000000fc 00000001 a428dd14 nt!NtWaitForSingleObject+0xbe
a428dd50 77279a94 000000fc 00000001 a428dd14 nt!KiFastCallEntry+0x12a
WARNING: Frame IP not in any known module. Following frames may be wrong.
035eff6c 00000000 00000000 00000000 00000000 0x77279a94


STACK_COMMAND:  kb

CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
    81ef49a4-81ef49ab  8 bytes - nt!KiServiceTable+34
 [ 57 17 0d 82 59 6e 03 82:a0 30 81 94 a8 dd 8b 94 ]
    81ef49b8-81ef49bb  4 bytes - nt!KiServiceTable+48 (+0x14)
 [ b9 e9 06 82:98 fb 56 93 ]
    81ef49c4-81ef49c7  4 bytes - nt!KiServiceTable+54 (+0x0c)
 [ 7f 80 02 82:68 1e 3c 94 ]
    81ef4a7c-81ef4a7f  4 bytes - nt!KiServiceTable+10c (+0xb8)
 [ c8 2a 07 82:a0 3e 81 94 ]
    81ef4aa8-81ef4aab  4 bytes - nt!KiServiceTable+138 (+0x2c)
 [ d4 fd 0c 82:38 4b 7e 94 ]
    81ef4b40-81ef4b43  4 bytes - nt!KiServiceTable+1d0 (+0x98)
 [ 68 34 0a 82:08 7a 8a 94 ]
    81ef4bbc-81ef4bbf  4 bytes - nt!KiServiceTable+24c (+0x7c)
 [ 17 dd ec 81:f8 f9 56 93 ]
    81ef4be0-81ef4be3  4 bytes - nt!KiServiceTable+270 (+0x24)
 [ 0f 72 ff 81:90 3f 81 94 ]
    81ef4be8-81ef4beb  4 bytes - nt!KiServiceTable+278 (+0x08)
 [ 29 98 00 82:98 39 81 94 ]
    81ef4c34-81ef4c37  4 bytes - nt!KiServiceTable+2c4 (+0x4c)
 [ 42 06 06 82:18 f9 56 93 ]
    81ef4c50-81ef4c53  4 bytes - nt!KiServiceTable+2e0 (+0x1c)
 [ e3 1f 02 82:00 3e 81 94 ]
    81ef4c7c-81ef4c7f  4 bytes - nt!KiServiceTable+30c (+0x2c)
 [ a5 91 04 82:78 4a 7e 94 ]
    81ef4c84-81ef4c87  4 bytes - nt!KiServiceTable+314 (+0x08)
 [ e6 46 06 82:f8 35 81 94 ]
    81ef4c98-81ef4c9b  4 bytes - nt!KiServiceTable+328 (+0x14)
 [ 7b 99 04 82:a8 1d 23 95 ]
    81ef4dd8-81ef4ddb  4 bytes - nt!KiServiceTable+468 (+0x140)
 [ 8a d4 03 82:88 43 7e 94 ]
    81ef4df4-81ef4df7  4 bytes - nt!KiServiceTable+484 (+0x1c)
 [ 9f 0a 0d 82:e8 b8 07 94 ]
    81ef4e34-81ef4e3b  8 bytes - nt!KiServiceTable+4c4 (+0x40)
 [ 75 05 07 82 1a ea 03 82:78 1e 23 95 38 a4 7d 94 ]
    81ef4e98-81ef4e9f  8 bytes - nt!KiServiceTable+528 (+0x64)
 [ 93 16 0d 82 b8 e6 08 82:40 7a 8a 94 f0 fb 56 93 ]
    81ef4ea8-81ef4eaf  8 bytes - nt!KiServiceTable+538 (+0x10)
 [ 84 ee 01 82 1d b6 04 82:e8 4c 7e 94 d0 6b 1f 94 ]
    81ef4ee0-81ef4ee3  4 bytes - nt!KiServiceTable+570 (+0x38)
 [ 99 0c 06 82:48 1f 23 95 ]
    81ef4f08-81ef4f0b  4 bytes - nt!KiServiceTable+598 (+0x28)
 [ 5d 9b 04 82:c8 fa 56 93 ]
100 errors : !nt (81ef49a4-81ef4f0b)

MODULE_NAME: memory_corruption

IMAGE_NAME:  memory_corruption

FOLLOWUP_NAME:  memory_corruption

DEBUG_FLR_IMAGE_TIMESTAMP:  0

MEMORY_CORRUPTOR:  LARGE

FAILURE_BUCKET_ID:  MEMORY_CORRUPTION_LARGE

BUCKET_ID:  MEMORY_CORRUPTION_LARGE

Followup: memory_corruption
---------

 

Back to Top
molotov View Drop Down
Moderator Group
Moderator Group
Avatar

Joined: 04 October 2006
Online Status: Offline
Posts: 17492
Post Options Post Options   Quote molotov Quote  Post ReplyReply Direct Link To This Post Posted: 04 April 2008 at 9:30am
A PDB is a program database file.  When you build an executable module (DLL or EXE) you can instruct the development environment to generate a PDB that contains symbol information, useful for debugging.  Generally, this PDB is given the same name as the module, with a .pdb extension.  The PDB does not need to be present in order for the module to work.  But debuggers and other tools can use the PDB, if available, to provide additional information.  So, in the case of a0baupx2.sys, I looked at the memory into which the module was loaded, and found the string "C:\dtscsi.pdb" (the path to the PDB is often times found a binary).
 
DTSCSI.SYS would seem to be the Daemon Tools SCSI driver, which for whatever reason appears to be randomly named and loaded.


Edited by molotov - 04 April 2008 at 9:31am
Daily affirmation:
net helpmsg 4006
Back to Top
 Post Reply Post Reply Page  123 4>

Forum Jump Forum Permissions View Drop Down