![]() |
MiSystemVaType memory? |
Post Reply
|
Page 123 4> |
| Author | |
jhoffa
Groupie
Joined: 03 March 2008 Online Status: Offline Posts: 47 |
Post Options
Quote Reply
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.
|
|
![]() |
|
molotov
Moderator Group
Joined: 04 October 2006 Online Status: Offline Posts: 17492 |
Post Options
Quote Reply
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 |
|
![]() |
|
jhoffa
Groupie
Joined: 03 March 2008 Online Status: Offline Posts: 47 |
Post Options
Quote Reply
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
|
|
![]() |
|
molotov
Moderator Group
Joined: 04 October 2006 Online Status: Offline Posts: 17492 |
Post Options
Quote Reply
Posted: 11 April 2008 at 5:53pm |
|
If NTKRNLPA.EXE verifies with Sigcheck, the disk file is probably OK...
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 |
|
![]() |
|
jhoffa
Groupie
Joined: 03 March 2008 Online Status: Offline Posts: 47 |
Post Options
Quote Reply
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? 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. |
|
![]() |
|
molotov
Moderator Group
Joined: 04 October 2006 Online Status: Offline Posts: 17492 |
Post Options
Quote Reply
Posted: 05 April 2008 at 7:16pm |
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 |
|
![]() |
|
jhoffa
Groupie
Joined: 03 March 2008 Online Status: Offline Posts: 47 |
Post Options
Quote Reply
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. |
|
![]() |
|
molotov
Moderator Group
Joined: 04 October 2006 Online Status: Offline Posts: 17492 |
Post Options
Quote Reply
Posted: 05 April 2008 at 2:46pm |
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 |
|
![]() |
|
jhoffa
Groupie
Joined: 03 March 2008 Online Status: Offline Posts: 47 |
Post Options
Quote Reply
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) Debugging Details:
PEB is paged out (Peb.Ldr = 7ffd400c). Type ".hh dbgerr001" for details READ_ADDRESS: 01f3a3bc CURRENT_IRQL: 1b FAULTING_IP: DEFAULT_BUCKET_ID: CODE_CORRUPTION BUGCHECK_STR: 0xA PROCESS_NAME: LCDMon.exe TRAP_FRAME: a428dbfc -- (.trap 0xffffffffa428dbfc) LAST_CONTROL_TRANSFER: from 81ef4865 to 81e96d84 STACK_TEXT:
CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt 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
|
|
![]() |
|
molotov
Moderator Group
Joined: 04 October 2006 Online Status: Offline Posts: 17492 |
Post Options
Quote Reply
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 |
|
![]() |
|
Post Reply
|
Page 123 4> |
| Forum Jump | Forum Permissions ![]() You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |