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
  Topic Search Topic Search  Topic Options Topic Options
jhoffa View Drop Down
Groupie
Groupie


Joined: 03 March 2008
Online Status: Offline
Posts: 47 		  Quote jhoffa Quote  Post ReplyReply Direct Link To This Post Topic: MiSystemVaType memory?
    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
Executable search path is:
Windows Vista Kernel Version 6000 MP (4 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 6000.16575.x86fre.vista_gdr.071009-1548
Kernel base = 0x82000000 PsLoadedModuleList = 0x82111e10
Debug session time: Mon Feb  4 20:28:11.454 2008 (GMT-7)
System Uptime: 0 days 6:36:39.576
Loading Kernel Symbols
........................................................................................................................................................................
Loading User Symbols
Loading unloaded module list
..................................................
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

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
*******************************************************************************
*                                                                             *
*                        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: 1443a0c4, memory referenced
Arg2: 0000001b, IRQL
Arg3: 00000001, 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: 820ad9da, address which referenced memory

Debugging Details:
------------------
WRITE_ADDRESS: GetPointerFromAddress: unable to read from 821315ac
Unable to read MiSystemVaType memory at 821117e0
 1443a0c4

CURRENT_IRQL:  1b

FAULTING_IP:
nt!KiInsertTimerTable+4e
820ad9da 894f04          mov     dword ptr [edi+4],ecx

CUSTOMER_CRASH_COUNT:  2

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0xA

PROCESS_NAME:  System

TRAP_FRAME:  82c9eba8 -- (.trap 0xffffffff82c9eba8)
ErrCode = 00000002
eax=820fa400 ebx=00000037 ecx=9f60b840 edx=00001a40 esi=820fa400 edi=1443a0c0
eip=820ad9da esp=82c9ec1c ebp=82c9ec38 iopl=0         nv up ei pl zr na pe nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010246
nt!KiInsertTimerTable+0x4e:
820ad9da 894f04          mov     dword ptr [edi+4],ecx ds:0023:1443a0c4=????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from 820ad9da to 8208fd84

STACK_TEXT: 
82c9eba8 820ad9da badb0d00 00001a40 ffffff00 nt!KiTrap0E+0x2ac
82c9ec38 82028c35 00000002 997f2008 00000000 nt!KiInsertTimerTable+0x4e
82c9ec80 8d78abab 00000002 82c9ecb4 00000001 nt!KeWaitForMultipleObjects+0x44e
82c9ecc8 8d767197 00000002 86fb9460 86f48690 dxgkrnl!VidSchiWaitForSchedulerEvents+0x109
82c9ed58 8d78b0d5 997f2008 00000000 997f2008 dxgkrnl!VidSchiScheduleCommandToRun+0xac
82c9ed6c 8d7cb191 997f2008 9f60b7a0 82c9edc0 dxgkrnl!VidSchiRun_PriorityTable+0xf
82c9ed7c 822254e0 997f2008 82c95680 00000000 dxgkrnl!VidSchiWorkerThread+0x61
82c9edc0 8209159e 8d7cb130 997f2008 00000000 nt!PspSystemThreadStartup+0x9d
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


STACK_COMMAND:  kb

FOLLOWUP_IP:
dxgkrnl!VidSchiWaitForSchedulerEvents+109
8d78abab 8bf8            mov     edi,eax

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
---------
Back to Top
molotov View Drop Down
Moderator Group
Moderator Group
Avatar

Joined: 04 October 2006
Online Status: Offline
Posts: 17287 		  Quote molotov Quote  Post ReplyReply Direct Link To This Post 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
Back to Top
jhoffa View Drop Down
Groupie
Groupie


Joined: 03 March 2008
Online Status: Offline
Posts: 47 		  Quote jhoffa Quote  Post ReplyReply Direct Link To This Post 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.
Back to Top
molotov View Drop Down
Moderator Group
Moderator Group
Avatar

Joined: 04 October 2006
Online Status: Offline
Posts: 17287 		  Quote molotov Quote  Post ReplyReply Direct Link To This Post 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
Back to Top
jhoffa View Drop Down
Groupie
Groupie


Joined: 03 March 2008
Online Status: Offline
Posts: 47 		  Quote jhoffa Quote  Post ReplyReply Direct Link To This Post Posted: 01 April 2008 at 7:35am
Yep, I'm running SLi and have tried removing each card at a time (top slot, bottom slot, swapping slots), & various driver versions. Running single cards, removing sound cards, and removing each memory strip at a time on top of running memory sector tests. Spent the last 3 weeks or so swapping hardware. The system is watercooled and slots are tight on the board. It is slightly overclocked but ran a hard one month testing/benching run w/o any software installs before this problem occurred (and yep, I've tried clocking it back to stock on the bios as well). It started almost immediately after installing Razer mouse drivers. This has been ongoing for 3 months now (I've been stubborn on the OS reinstall, I really want to see what's been causing this before I wipe the slate). The only thing I haven't swapped out is the mboard. I don't have another board that fits my components to test with.
Back to Top
molotov View Drop Down
Moderator Group
Moderator Group
Avatar

Joined: 04 October 2006
Online Status: Offline
Posts: 17287 		  Quote molotov Quote  Post ReplyReply Direct Link To This Post Posted: 01 April 2008 at 7:40am
Have you tried chkdsk /r?  Any drive diagnostics?
 
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?
Would think that Windows Resource Protection would detect / prevent this.   Have you tried SFC?
Daily affirmation:
net helpmsg 4006
Back to Top
jhoffa View Drop Down
Groupie
Groupie


Joined: 03 March 2008
Online Status: Offline
Posts: 47 		  Quote jhoffa Quote  Post ReplyReply Direct Link To This Post Posted: 01 April 2008 at 8:50am

Ran both again before I went to the office. No problems detected, no integrity violations. From what I was aware, WRP only protects against drivers not signed by one of the eight trusted root authorities? Patchguard prevents kernel patching, but is 64bit only I think.

Off topic a bit, but Symantec advanced threat research has a great article on Kernel-Mode Security that you might find interesting. Mark's book was listed in the references as well.
Back to Top
molotov View Drop Down
Moderator Group
Moderator Group
Avatar

Joined: 04 October 2006
Online Status: Offline
Posts: 17287 		  Quote molotov Quote  Post ReplyReply Direct Link To This Post Posted: 01 April 2008 at 8:56am
Man - chkdsk ran fast...  Manufacturer drive diagnostics give anything?
 
From what I was aware, WRP only protects against drivers not signed by one of the eight trusted root authorities?
No, it would seem to be broader than just drivers.
About Windows Resource Protection
Windows Resource Protection (WRP) prevents the replacement of essential system files, folders, and registry keys that are installed as part of Windows Server 2008 and Windows Vista...
 
Patchguard prevents kernel patching, but is 64bit only I think.
Correct - x64 only - not IA64.
 
 
Daily affirmation:
net helpmsg 4006
Back to Top
jhoffa View Drop Down
Groupie
Groupie


Joined: 03 March 2008
Online Status: Offline
Posts: 47 		  Quote jhoffa Quote  Post ReplyReply Direct Link To This Post Posted: 01 April 2008 at 9:19am
Man - chkdsk ran fast...  Manufacturer drive diagnostics give anything?
 
Screaming quad extreme clocked at 4 per core. I love this rig... I'd love it even more without the blues. Nope they came up clean although I haven't run them since the first month of crashes.
 
No, it would seem to be broader than just drivers.
About Windows Resource Protection[quote]Windows Resource Protection (WRP) prevents the replacement of essential system files, folders, and registry keys that are installed as part of Windows Server 2008 and Windows Vista...
 
I just meant specifically regarding the driver issue. As long as winload.exe verifies integrity checks/signing, the driver can then patch the kernel. Is this correct? I've been trying to get more information from Razer as well, but they've been giving me the long run around. I've offered them my dumps as well as detailed information about my system. Their persistant answer is, "We have many users that use Vista with no problems."
Back to Top
molotov View Drop Down
Moderator Group
Moderator Group
Avatar

Joined: 04 October 2006
Online Status: Offline
Posts: 17287 		  Quote molotov Quote  Post ReplyReply Direct Link To This Post Posted: 01 April 2008 at 10:08am
I know you stated you had stopped overclocking for a while.  Does doing so reduce the variety / frequency of the crashes?  Is is possible that the hardware has been damaged as a result of overclocking, such that ceasing to overclock will have no impact?
 
Can you uplaod a minidump of one of the crashes?
 
If you suspect a problem with the software for the Razer mouse, have you eliminated it completely from the picture?  (No drivers, no support utility, etc.)?
Daily affirmation:
net helpmsg 4006
Back to Top
 Post Reply Post Reply Page  123 4>

Forum Jump Forum Permissions View Drop Down

Privacy Statement