|
MiSystemVaType memory? |
Post Reply 
|
Page <1 234 |
| Author |
 Share Topic Printable Version Delicious Digg Facebook Furl Google MySpace Newsvine reddit StumbleUpon Translate Twitter Windows Live Yahoo Bookmarks Topic Search  Topic Options
|
molotov 
Moderator Group 
Joined: 04 October 2006 Online Status: Offline Posts: 17492 |
 Post Options
 Quote Reply
 Topic: MiSystemVaType memory?Posted: 01 April 2008 at 7:03am |
|
From the frequency and the variety of the crashes you describe, it sounds like you could have a hardware problem. You might consider selectively removing / swapping hardware, one component at a time, and running any manufacturer and other diagnostics you can think of. If you are able, isolate and run the memory strips separate from each other - for example, if you have 2 1 GB strips, test them in the system one at a time if possible. Even consider walking the slots (if you have a strip in one slot and get a crash, move it to another slot on the board, if you can).
Also, ensure that all connections are tight, and there is adequate cooling and airflow.
|
|
|
Daily affirmation:
net helpmsg 4006 |
|
 |
|
|
jhoffa
Groupie 
Joined: 03 March 2008 Online Status: Offline Posts: 47 |
Post Options
Quote Reply
Posted: 01 April 2008 at 6:57am |
|
No I haven't tried OCA but thank you for the advice, I'll head there in a bit. The odd thing is the crashes vary (dxg is one of many) from explorer.exe to usbhub.sys to to process idle to mouse drivers to win32k.sys to todays crash being ntkrpamp.exe. Every crash is a different process. That's why I originally suspected a memory crash, but memory has been testing fine after a 24 hour memory run. Problems and solutions listed 36 different solutions none of which has worked. I have to say Vista's problems and solutions are getting much better though. I've been submitting everything through there.
|
|
|
|
|
molotov
Moderator Group
Joined: 04 October 2006 Online Status: Offline Posts: 17492 |
Post Options
Quote Reply
Posted: 01 April 2008 at 3:59am |
|
Hi jhoffa,
Obvoiusly, in this case, dxgkrnl is the "the Microsoft DirectX graphics kernel subsystem", which would seem to be related to video.
Have you tried submitting any crashes to Microsoft's OCA (online crash analysis)? Have you checked out Vista's "Problem Reports and Solutions" - anything if you choose "Check for a solution" for a problem?
|
|
|
Daily affirmation:
net helpmsg 4006 |
|
|
|
|
jhoffa
Groupie
Joined: 03 March 2008 Online Status: Offline Posts: 47 |
Post Options
Quote Reply
Posted: 31 March 2008 at 9:11pm |
|
I've been dealing with a pretty ugly BSOD at home. A daily IRQL_NOT_LESS_OR_EQUAL. I understand that this BSOD usually involves either driver or memory issues. I've had a difficult time narrowing it down and have been systematically going through crash dumps. The system is running Vista 32 and I've gone through removing each component one at a time (sound, video, drives +extensive memory tests) as well as systematically removing and reinstalling drivers and I still get the BSOD daily. The bucket IDs state VISTA_DRIVER_FAULT but almost every crash references a different process name. The only thing I could find in common between the dumps (apart from IRQL 1b and VISTA_DRIVER_FAULT) was "Unable to read MiSystemVaType memory at 821117e0" and "Arg4: 820ad9da, address which referenced memory". Almost all of the dumps reference XXX117e0 and XXXad9da. What are these two addresses? What does MiSystemVaType mean? It's difficult to Google because it just brings up other debugs and nothing comes up on Microsoft support. Any other ideas on what I might try?I "suspect" that the original problem was caused by the installation of a Razer mouse driver (long since removed, using Logitech now) that modified ntkrnlpa.exe in some way? I had a brief 1.5 month break from the bluescreens after reinstalling a service pack in an attempt to "patch" this. Then a video driver crash brought it back daily again.
Below is a sample debug of one of the dumps. The "probably caused by" changes in almost every dump (36 dumps so far).
Microsoft (R) Windows Debugger Version 6.8.0004.0 X86
Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [D:\Dumps\Mini020408-02.dmp] Mini Kernel Dump File: Only registers and stack trace are available Symbol search path is: srv*C:\Symbols*http://msdl.microsoft.com/download/symbols Use !analyze -v to get detailed debugging information. BugCheck A, {1443a0c4, 1b, 1, 820ad9da} Probably caused by : dxgkrnl.sys ( dxgkrnl!VidSchiWaitForSchedulerEvents+109 ) Followup: MachineOwner 1: kd> !analyze -v IRQL_NOT_LESS_OR_EQUAL (a) Debugging Details: CURRENT_IRQL: 1b FAULTING_IP: CUSTOMER_CRASH_COUNT: 2 DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT BUGCHECK_STR: 0xA PROCESS_NAME: System TRAP_FRAME: 82c9eba8 -- (.trap 0xffffffff82c9eba8) LAST_CONTROL_TRANSFER: from 820ad9da to 8208fd84 STACK_TEXT: STACK_COMMAND: kb FOLLOWUP_IP: SYMBOL_STACK_INDEX: 3 SYMBOL_NAME: dxgkrnl!VidSchiWaitForSchedulerEvents+109 FOLLOWUP_NAME: MachineOwner MODULE_NAME: dxgkrnl IMAGE_NAME: dxgkrnl.sys DEBUG_FLR_IMAGE_TIMESTAMP: 473baa5b FAILURE_BUCKET_ID: 0xA_W_dxgkrnl!VidSchiWaitForSchedulerEvents+109 BUCKET_ID: 0xA_W_dxgkrnl!VidSchiWaitForSchedulerEvents+109 Followup: MachineOwner |
|
|
|
|
Post Reply
|
Page <1 234 |
| 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 |
