The new forums will be named Coin Return (based on the most recent vote)! You can check on the status and timeline of the transition to the new forums here.
The Guiding Principles and New Rules document is now in effect.
So, I'm brand new to Vista and 64 bit OSs in general. As a result I've run into apparently a semi common thing in Vista that I'd never heard of before? I get BSODs about once or so a day, with errors like 'page fault in non paged area' and something like 'an attempt was made to modify a critical system process'.
Google searches point to something of a compatibility issue as far as I can tell with programs and my OS, but I haven't really seen anything that pointed my programs out as not playing nice with Vista.
For reference, here's what I currently have:
I'm using Vista 64 Home Premium.
Replace the power supply with the corsair one suggested in the OP and that's what I currently have.
I think that about covers it. Any help would be greatly appreciated. And if anyone has any general tips and tricks for 64 vista that make your life easier, that would also be very nice.
Clean install. Brand new computer, only a couple of weeks old. I've since updated my audio and video drivers. I know they're the right ones because I have all of my documentation with me. Which, you know, makes driver updating so much easier.
That's...odd. This morning I woke up to a memory management problem. Never had that error before. Why does this thing only seem to happen at night. Maybe AVG is the culprit? That's the only thing I can think of that runs every night.
Run a test on your RAM, sounds like it could be a faulty stick
Page fault in non-paged area often = bad memory, definitely do a memtest (Vista can do them on boot, hit F8 to bring up the menu.) I would guess AVG is just triggering the event because an active scan is very resource intensive.
The process that triggers the event isn't always the cause of the issue. Fault in non-paged means it's occurring in your physical memory (or memory that the OS is not paging but nonetheless does not mean it's your physical memory, not always the same thing - shitty, I know). These types of issues can be misleading sometimes, as mem tests may eventually flag a module bad, but you can go to town in a different OS on the same system and never have a problem. Or, it's a hardware problem deeper than the memory stick/module but the mem test assumes it's the stick.
Good luck with that. In these cases I just usually get as much supporting evidence as I can that the module is bad and pressure the vendor into replacing it. If that doesn't fix it it's onto the joy of reinstalling Windows and building the system back up driver-by-driver and app-by-app.
Well the mem test came back clean, thank god. On another happy note, I finally figured out how to access the mini dumps windows has been generating with these BSODs.
Here they are, spanning four dumps over four days. Some of the data seems very specific, but I'm not sure exactly what it's pointing to.
As you can see they're generally one a day, and they started about a week and a half or so after I got this thing.
4/04/09
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: fffffa6001bc0000, memory referenced.
Arg2: 0000000000000000, value 0 = read operation, 1 = write operation.
Arg3: fffffa800a37f55c, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 0000000000000000, (reserved)
Debugging Details:
Could not read faulting driver name
READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80002046080
fffffa6001bc0000
FAULTING_IP:
+6bb5952f02d0dc58
fffffa80`0a37f55c 58 pop rax
MM_INTERNAL_CODE: 0
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0x50
PROCESS_NAME: System
CURRENT_IRQL: 0
TRAP_FRAME: fffffa6001bbfe70 -- (.trap 0xfffffa6001bbfe70)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000040 rbx=0000000000000000 rcx=fffffa600074c7b5
rdx=000000003884f9d0 rsi=0000000000000000 rdi=0000000000000000
rip=fffffa800a37f55c rsp=fffffa6001bc0000 rbp=fffffa6001bbf700
r8=0000000000000085 r9=fffffa600074c730 r10=0000000000000000
r11=fffffa6000742e10 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
fffffa80`0a37f55c 58 pop rax
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff80001e81361 to fffff80001e72350
FOLLOWUP_IP:
nt!KiPageFault+119
fffff800`01e70ed9 85c0 test eax,eax
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: nt!KiPageFault+119
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 48d1ba35
FAILURE_BUCKET_ID: X64_0x50_nt!KiPageFault+119
BUCKET_ID: X64_0x50_nt!KiPageFault+119
Followup: MachineOwner
4/05/09
CRITICAL_STRUCTURE_CORRUPTION (109)
This bugcheck is generated when the kernel detects that critical kernel code or
data have been corrupted. There are generally three causes for a corruption:
1) A driver has inadvertently or deliberately modified critical kernel code
or data. See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
2) A developer attempted to set a normal kernel breakpoint using a kernel
debugger that was not attached when the system was booted. Normal breakpoints,
"bp", can only be set if the debugger is attached at boot time. Hardware
breakpoints, "ba", can be set at any time.
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arguments:
Arg1: a3a039d89bb74896, Reserved
Arg2: 0000000000000000, Reserved
Arg3: 7e18eba1a8e616db, Failure type dependent information
Arg4: 0000000000000101, Type of corrupted region, can be
0 : A generic data region
1 : Modification of a function or .pdata
2 : A processor IDT
3 : A processor GDT
4 : Type 1 process list corruption
5 : Type 2 process list corruption
6 : Debug routine modification
7 : Critical MSR modification
Debugging Details:
BUGCHECK_STR: 0x109
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: System
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 0000000000000000 to fffff80001ea4350
MEMORY_MANAGEMENT (1a)
# Any other values for parameter 1 must be individually examined.
Arguments:
Arg1: 0000000000005003, The subtype of the bugcheck.
Arg2: fffff78000001000
Arg3: 00000000000205e8
Arg4: fffff8800bf9be01
Debugging Details:
BUGCHECK_STR: 0x1a_5003
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: uTorrent.exe(this seems like it could be important, but I haven't read anything about utorrent not playing nice with vista 64. They're forums seem to indicate, like you guys thought about AVG, that utorrent was triggering the problem with its work. but then again the mem test came back clean, soo.)
CURRENT_IRQL: 0
TRAP_FRAME: fffffa6009899200 -- (.trap 0xfffffa6009899200)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fa800416081004c0 rbx=0000000000000000 rcx=0000000000138440
rdx=ffa8004160810000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80001e9762b rsp=fffffa6009899390 rbp=00000000000fd680
r8=000000000000040e r9=00000000000007ff r10=0000000000000801
r11=0000000000000265 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na po cy
nt!MiAddViewsForSection+0x17b:
fffff800`01e9762b f348ab rep stos qword ptr [rdi]
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff80001ebec38 to fffff80001e62350
CRITICAL_STRUCTURE_CORRUPTION (109)
This bugcheck is generated when the kernel detects that critical kernel code or
data have been corrupted. There are generally three causes for a corruption:
1) A driver has inadvertently or deliberately modified critical kernel code
or data. See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
2) A developer attempted to set a normal kernel breakpoint using a kernel
debugger that was not attached when the system was booted. Normal breakpoints,
"bp", can only be set if the debugger is attached at boot time. Hardware
breakpoints, "ba", can be set at any time.
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arguments:
Arg1: a3a039d89be6d8d1, Reserved
Arg2: 0000000000000000, Reserved
Arg3: e784fc6822d311a3, Failure type dependent information
Arg4: 0000000000000101, Type of corrupted region, can be
0 : A generic data region
1 : Modification of a function or .pdata
2 : A processor IDT
3 : A processor GDT
4 : Type 1 process list corruption
5 : Type 2 process list corruption
6 : Debug routine modification
7 : Critical MSR modification
Debugging Details:
BUGCHECK_STR: 0x109
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: System
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 0000000000000000 to fffff80001e9b350
Any chance you can get your hands on some alternative sticks of RAM for a day or two? Those still point at intermittent memory corruption in non-paged kernel memory.
User space programs that happen to be running when it happens, like uTorrent, are likely coincidental rather than causative.
It could be a misbehaving driver crapping on your kernel, and you could try uninstalling drivers and AVG (like most anti-virus programs I assume it has some components which patch kernel address space) and see if that alleviates it, but I would expect there to be more widespread reports from people using the affected driver if that were the case.
edit: how long did you run the memory test for? I'd run memtest86 for 24-48 hours before trying to draw any conclusions from the results
Any chance you can get your hands on some alternative sticks of RAM for a day or two? Those still point at intermittent memory corruption in non-paged kernel memory.
User space programs that happen to be running when it happens, like uTorrent, are likely coincidental rather than causative.
It could be a misbehaving driver crapping on your kernel, and you could try uninstalling drivers and AVG (like most anti-virus programs I assume it has some components which patch kernel address space) and see if that alleviates it, but I would expect there to be more widespread reports from people using the affected driver if that were the case.
edit: how long did you run the memory test for? I'd run memtest86 for 24-48 hours before trying to draw any conclusions from the results
I just let the windows thing run over night. When I logged into my computer this morning, it told me no errors were detected.
I guess I could do your thing! Although it would suck to go without my only pc for that long.
That makes sense. mostly I'm just concerned that the error is intermittent enough that it just happened to not occur during testing, and I'm not familiar with how stressful the built-in windows mem tester is
That makes sense. mostly I'm just concerned that the error is intermittent enough that it just happened to not occur during testing, and I'm not familiar with how stressful the built-in windows mem tester is
Indeed. I'm not exactly sure how stress from games compares to stress from say, uTorrent and virus scanners, but the fact that it only seems to happen at night and when I'm not using it strikes me as the oddest thing. If we're talking about stress, I've been playing games like Crysis, Fallout 3, Dead Sapce, etc on very high settings, and it hasn't crashed once. Okay well Fallout crashed a lot but that was to desktop and I'm pretty sure it was the game's fault >_>
is the mobo I have. As far as I can tell, it's Intel all the way. As far as drivers go, I used the ASUS cd that came with the mobo to install all of the basic stuff, but since then I've updated the audio, video, and chipset drives manually.
Unfortunately my computer seems to be just straight up resetting these days...the event log just says that the OS shutdown unexpectedly. I'm assuming that's another sign of faulty RAM, eh
Although now that I look closer, two instances of
\SystemRoot\SysWow64\Drivers\ULCDRHlp.sys has been blocked from loading due to incompatibility with this system. Please contact your software vendor for a compatible version of the driver.
crop up before the system 'shuts down unexpectedly'. I know this is a terribly selfish thing to do, but I am pretty drunk right now, so I'll just leave this up until tomorrow morning when I am sober. If anyone has any suggestions in the meantime I would really appreciate it and will follow up.
edit; okay I've sobered up enough to realize that a google search would be simple enough for my current mental capacity. ULCDRBHlp.sys is a free burning utility that came with the motherboard. I'll try uninstalling that and see if that helps. But, again, I installed that the very first time I booted into my OS, and these problems cropped up a week+ afterward.
Sounds like you're running 32bit drivers on your 64bit system. Or unsigned drivers on your 64bit system. See if ULead has a patch to fix that burning program.
SiliconStew on
Just remember that half the people you meet are below average intelligence.
0
Zilla36021st Century. |She/Her|Trans* Woman In Aviators Firing A Bazooka. ⚛️Registered Userregular
edited April 2009
I'd run memtest86 for 24 hours or so. Comes on every Ubuntu Live CD.
In fact I'd test with 64bit Ubuntu too, see if you get any Kernel Panics.
Lots of Filesystem calls.
Looks like data is being corrupted either in RAM or in the process of being transferred from your HD to RAM.
The latter would indicate a faulty motherboard chipset or drivers.
Right, so still having this problem. I'm planning to run memtest this weekend if I can't fix the problem by then, so that's definitely in the works.
Meanwhile, I was planning to swap out my RAM with my brother in law's, they're both the same size and frequency. I noticed his RAM was set up a particular way with his four RAM slots. I've never had four RAM slots in a mobo before, so I asked him about it. Turns out apparently I'm supposed to set the RAM a particular way >_>. I probably should have taken notice of the color schemes. The end result is that my ram was seated in the 0 and 2 slot instead of slots 0 and 1. So, that's been taken care of and I'm going to see what happens.
I now know that seating the RAM the way I had it was a Bad Thing, but do you guys think it could have been causing these problems?
I would recommend a reinstall and avoid using the Driver CD. Download up to date Vista drivers for your mobo directly from Intel's site. I had problems with my sister's PC that I built for her a month after Vista's launch. She has an Intel mobo and I had to do the same for her.
If you need a Vista disc PM me for a link. As long as your key is legal MS doesn't care where the disc comes from.
So, after re-seating the RAM it's been two days since I had a crash. Which is enough time for me to tentatively say it's been fixed.
Thank you all very much for your help. Sorry it turned out to be something as boneheaded as this. I re-read the manual and saw where it recommended seating it. Must have just skimmed over it while I was thinking OH JEEZ RAM I KNOW HOW TO DO THAT.
Posts
GT: Tanky the Tank
Black: 1377 6749 7425
On the black screen
On the black screen
Page fault in non-paged area often = bad memory, definitely do a memtest (Vista can do them on boot, hit F8 to bring up the menu.) I would guess AVG is just triggering the event because an active scan is very resource intensive.
Good luck with that. In these cases I just usually get as much supporting evidence as I can that the module is bad and pressure the vendor into replacing it. If that doesn't fix it it's onto the joy of reinstalling Windows and building the system back up driver-by-driver and app-by-app.
Here they are, spanning four dumps over four days. Some of the data seems very specific, but I'm not sure exactly what it's pointing to.
As you can see they're generally one a day, and they started about a week and a half or so after I got this thing.
4/04/09
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: fffffa6001bc0000, memory referenced.
Arg2: 0000000000000000, value 0 = read operation, 1 = write operation.
Arg3: fffffa800a37f55c, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 0000000000000000, (reserved)
Debugging Details:
Could not read faulting driver name
READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80002046080
fffffa6001bc0000
FAULTING_IP:
+6bb5952f02d0dc58
fffffa80`0a37f55c 58 pop rax
MM_INTERNAL_CODE: 0
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0x50
PROCESS_NAME: System
CURRENT_IRQL: 0
TRAP_FRAME: fffffa6001bbfe70 -- (.trap 0xfffffa6001bbfe70)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000040 rbx=0000000000000000 rcx=fffffa600074c7b5
rdx=000000003884f9d0 rsi=0000000000000000 rdi=0000000000000000
rip=fffffa800a37f55c rsp=fffffa6001bc0000 rbp=fffffa6001bbf700
r8=0000000000000085 r9=fffffa600074c730 r10=0000000000000000
r11=fffffa6000742e10 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
fffffa80`0a37f55c 58 pop rax
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff80001e81361 to fffff80001e72350
STACK_TEXT:
fffffa60`01bbfd78 fffff800`01e81361 : 00000000`00000050 fffffa60`01bc0000 00000000`00000000 fffffa60`01bbfe70 : nt!KeBugCheckEx
fffffa60`01bbfd80 fffff800`01e70ed9 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!MmAccessFault+0x1371
fffffa60`01bbfe70 fffffa80`0a37f55c : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiPageFault+0x119
fffffa60`01bc0000 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0xfffffa80`0a37f55c
STACK_COMMAND: kb
FOLLOWUP_IP:
nt!KiPageFault+119
fffff800`01e70ed9 85c0 test eax,eax
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: nt!KiPageFault+119
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 48d1ba35
FAILURE_BUCKET_ID: X64_0x50_nt!KiPageFault+119
BUCKET_ID: X64_0x50_nt!KiPageFault+119
Followup: MachineOwner
4/05/09
This bugcheck is generated when the kernel detects that critical kernel code or
data have been corrupted. There are generally three causes for a corruption:
1) A driver has inadvertently or deliberately modified critical kernel code
or data. See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
2) A developer attempted to set a normal kernel breakpoint using a kernel
debugger that was not attached when the system was booted. Normal breakpoints,
"bp", can only be set if the debugger is attached at boot time. Hardware
breakpoints, "ba", can be set at any time.
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arguments:
Arg1: a3a039d89bb74896, Reserved
Arg2: 0000000000000000, Reserved
Arg3: 7e18eba1a8e616db, Failure type dependent information
Arg4: 0000000000000101, Type of corrupted region, can be
0 : A generic data region
1 : Modification of a function or .pdata
2 : A processor IDT
3 : A processor GDT
4 : Type 1 process list corruption
5 : Type 2 process list corruption
6 : Debug routine modification
7 : Critical MSR modification
Debugging Details:
BUGCHECK_STR: 0x109
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: System
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 0000000000000000 to fffff80001ea4350
STACK_TEXT:
fffffa60`01bd4698 00000000`00000000 : 00000000`00000109 a3a039d8`9bb74896 00000000`00000000 7e18eba1`a8e616db : nt!KeBugCheckEx
STACK_COMMAND: kb
SYMBOL_NAME: ANALYSIS_INCONCLUSIVE
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: Unknown_Module
IMAGE_NAME: Unknown_Image
DEBUG_FLR_IMAGE_TIMESTAMP: 0
BUCKET_ID: BAD_STACK
Followup: MachineOwner
4/06/09
# Any other values for parameter 1 must be individually examined.
Arguments:
Arg1: 0000000000005003, The subtype of the bugcheck.
Arg2: fffff78000001000
Arg3: 00000000000205e8
Arg4: fffff8800bf9be01
Debugging Details:
BUGCHECK_STR: 0x1a_5003
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: uTorrent.exe(this seems like it could be important, but I haven't read anything about utorrent not playing nice with vista 64. They're forums seem to indicate, like you guys thought about AVG, that utorrent was triggering the problem with its work. but then again the mem test came back clean, soo.)
CURRENT_IRQL: 0
TRAP_FRAME: fffffa6009899200 -- (.trap 0xfffffa6009899200)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fa800416081004c0 rbx=0000000000000000 rcx=0000000000138440
rdx=ffa8004160810000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80001e9762b rsp=fffffa6009899390 rbp=00000000000fd680
r8=000000000000040e r9=00000000000007ff r10=0000000000000801
r11=0000000000000265 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na po cy
nt!MiAddViewsForSection+0x17b:
fffff800`01e9762b f348ab rep stos qword ptr [rdi]
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff80001ebec38 to fffff80001e62350
STACK_TEXT:
fffffa60`09898f18 fffff800`01ebec38 : 00000000`0000001a 00000000`00005003 fffff780`00001000 00000000`000205e8 : nt!KeBugCheckEx
fffffa60`09898f20 fffff800`01e8833a : 00000000`00000001 fffff880`2b919000 fffff800`01fd3220 fffff6fb`7e200b08 : nt! ?? ::FNODOBFM::`string'+0x15d0a
fffffa60`09898fb0 fffff800`01e714b9 : 00000000`00000000 fffff880`2b919000 00000000`00000000 00000000`00000000 : nt!MiDispatchFault+0x7ea
fffffa60`09899110 fffff800`01e60ed9 : 00000000`00000001 fffffa60`019de000 00000000`00000800 fffffa80`04160810 : nt!MmAccessFault+0x14c9
fffffa60`09899200 fffff800`01e9762b : fffffa80`74536d4d 00000000`00edb200 00000000`000fd680 00000000`00000090 : nt!KiPageFault+0x119
fffffa60`09899390 fffff800`01e96dee : fffff6fc`c0073800 00000000`00000000 00000000`000fd640 fffffa80`0793a801 : nt!MiAddViewsForSection+0x17b
fffffa60`098993e0 fffff800`01e95614 : 00000000`00000000 00000000`00000000 fffffa60`019d27f0 fffffa80`0514dc60 : nt!MmMapViewInSystemCache+0x11e
fffffa60`09899500 fffff800`01e7a4b8 : 00000000`00000000 fffff800`01f4010e 00000000`fd640000 00000000`00000000 : nt!CcGetVacbMiss+0x1a4
fffffa60`09899590 fffff800`020cc599 : 00000000`00000000 fffffa80`07f127b0 00000000`fd640000 fffffa80`042f7210 : nt!CcGetVirtualAddress+0x348
fffffa60`09899610 fffffa60`012110d6 : fffffa80`0741b200 fffffa60`098997a0 fffff880`00004000 fffffa60`009e4f01 : nt!CcCopyRead+0x149
fffffa60`09899730 fffffa60`01213249 : fffff880`07dc0140 fffffa60`09899920 00000001`db620000 fffff880`07dc0140 : Ntfs!NtfsCachedRead+0x176
fffffa60`09899780 fffffa60`01214b68 : fffffa80`06aa8490 fffffa80`042f7210 fffffa60`09899901 fffffa80`00000004 : Ntfs!NtfsCommonRead+0x469
fffffa60`098998f0 fffffa60`00760e17 : fffffa80`042f7568 fffffa80`042f7210 fffffa80`073a0040 fffffa80`06bad5b0 : Ntfs!NtfsFsdRead+0x1b8
fffffa60`098999a0 fffffa60`007600dd : fffffa80`042f7210 fffffa80`0741b200 fffffa80`073a0001 00000000`000004f0 : fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x227
fffffa60`09899a10 fffff800`020ef3dc : 00000000`00000001 fffff800`020b0caf 00000000`00000008 00000000`75be3380 : fltmgr!FltpDispatch+0xcd
fffffa60`09899a70 fffff800`020cc1bf : fffffa80`0741b200 fffffa80`0741b200 fffffa80`0741b200 fffffa60`09899ca0 : nt!IopSynchronousServiceTail+0x13c
fffffa60`09899ad0 fffff800`01e61df3 : 00000000`000004f0 00000000`00000000 00000000`00000000 00000000`00000000 : nt!NtReadFile+0x5fd
fffffa60`09899bb0 00000000`75be3917 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`0059f0b8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x75be3917
STACK_COMMAND: kb
FOLLOWUP_IP:
nt! ?? ::FNODOBFM::`string'+15d0a
fffff800`01ebec38 cc int 3
SYMBOL_STACK_INDEX: 1
SYMBOL_NAME: nt! ?? ::FNODOBFM::`string'+15d0a
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 48d1ba35
FAILURE_BUCKET_ID: X64_0x1a_5003_nt!_??_::FNODOBFM::_string_+15d0a
BUCKET_ID: X64_0x1a_5003_nt!_??_::FNODOBFM::_string_+15d0a
Followup: MachineOwner
This bugcheck is generated when the kernel detects that critical kernel code or
data have been corrupted. There are generally three causes for a corruption:
1) A driver has inadvertently or deliberately modified critical kernel code
or data. See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
2) A developer attempted to set a normal kernel breakpoint using a kernel
debugger that was not attached when the system was booted. Normal breakpoints,
"bp", can only be set if the debugger is attached at boot time. Hardware
breakpoints, "ba", can be set at any time.
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arguments:
Arg1: a3a039d89be6d8d1, Reserved
Arg2: 0000000000000000, Reserved
Arg3: e784fc6822d311a3, Failure type dependent information
Arg4: 0000000000000101, Type of corrupted region, can be
0 : A generic data region
1 : Modification of a function or .pdata
2 : A processor IDT
3 : A processor GDT
4 : Type 1 process list corruption
5 : Type 2 process list corruption
6 : Debug routine modification
7 : Critical MSR modification
Debugging Details:
BUGCHECK_STR: 0x109
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: System
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 0000000000000000 to fffff80001e9b350
STACK_TEXT:
fffffa60`01bdb698 00000000`00000000 : 00000000`00000109 a3a039d8`9be6d8d1 00000000`00000000 e784fc68`22d311a3 : nt!KeBugCheckEx
STACK_COMMAND: kb
SYMBOL_NAME: ANALYSIS_INCONCLUSIVE
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: Unknown_Module
IMAGE_NAME: Unknown_Image
DEBUG_FLR_IMAGE_TIMESTAMP: 0
BUCKET_ID: BAD_STACK
Followup: MachineOwner
On the black screen
User space programs that happen to be running when it happens, like uTorrent, are likely coincidental rather than causative.
It could be a misbehaving driver crapping on your kernel, and you could try uninstalling drivers and AVG (like most anti-virus programs I assume it has some components which patch kernel address space) and see if that alleviates it, but I would expect there to be more widespread reports from people using the affected driver if that were the case.
edit: how long did you run the memory test for? I'd run memtest86 for 24-48 hours before trying to draw any conclusions from the results
I just let the windows thing run over night. When I logged into my computer this morning, it told me no errors were detected.
I guess I could do your thing! Although it would suck to go without my only pc for that long.
I think first I'll just try things software side.
On the black screen
Indeed. I'm not exactly sure how stress from games compares to stress from say, uTorrent and virus scanners, but the fact that it only seems to happen at night and when I'm not using it strikes me as the oddest thing. If we're talking about stress, I've been playing games like Crysis, Fallout 3, Dead Sapce, etc on very high settings, and it hasn't crashed once. Okay well Fallout crashed a lot but that was to desktop and I'm pretty sure it was the game's fault >_>
On the black screen
http://www.newegg.com/Product/Product.aspx?Item=N82E16813131329
is the mobo I have. As far as I can tell, it's Intel all the way. As far as drivers go, I used the ASUS cd that came with the mobo to install all of the basic stuff, but since then I've updated the audio, video, and chipset drives manually.
Unfortunately my computer seems to be just straight up resetting these days...the event log just says that the OS shutdown unexpectedly. I'm assuming that's another sign of faulty RAM, eh
Although now that I look closer, two instances of crop up before the system 'shuts down unexpectedly'. I know this is a terribly selfish thing to do, but I am pretty drunk right now, so I'll just leave this up until tomorrow morning when I am sober. If anyone has any suggestions in the meantime I would really appreciate it and will follow up.
edit; okay I've sobered up enough to realize that a google search would be simple enough for my current mental capacity. ULCDRBHlp.sys is a free burning utility that came with the motherboard. I'll try uninstalling that and see if that helps. But, again, I installed that the very first time I booted into my OS, and these problems cropped up a week+ afterward.
On the black screen
In fact I'd test with 64bit Ubuntu too, see if you get any Kernel Panics.
Looks like data is being corrupted either in RAM or in the process of being transferred from your HD to RAM.
The latter would indicate a faulty motherboard chipset or drivers.
Meanwhile, I was planning to swap out my RAM with my brother in law's, they're both the same size and frequency. I noticed his RAM was set up a particular way with his four RAM slots. I've never had four RAM slots in a mobo before, so I asked him about it. Turns out apparently I'm supposed to set the RAM a particular way >_>. I probably should have taken notice of the color schemes. The end result is that my ram was seated in the 0 and 2 slot instead of slots 0 and 1. So, that's been taken care of and I'm going to see what happens.
I now know that seating the RAM the way I had it was a Bad Thing, but do you guys think it could have been causing these problems?
On the black screen
If you need a Vista disc PM me for a link. As long as your key is legal MS doesn't care where the disc comes from.
Thank you all very much for your help. Sorry it turned out to be something as boneheaded as this. I re-read the manual and saw where it recommended seating it. Must have just skimmed over it while I was thinking OH JEEZ RAM I KNOW HOW TO DO THAT.
On the black screen