If Windows is no longer able to access certain files, then it will bugcheck the system.
Two common ones are KERNEL_DATA_INPAGE_ERROR and PAGE_FAULT_IN_NONPAGED_AREA. Both indicate that Windows is unable to bring in paged data from page file. There's also a bunch of bugcheck codes that can be raised by ntfs.sys and so on (INACCESSIBLE_BOOT_DEVICE, NTFS_FILE_SYSTEM etc). Easy to test - just setup a virtual machine on your laptop, and put the VHD/VMDK file on an external USB drive. Then pull the plug on the USB drive, and the VM will blue screen. Cheers Ken ________________________________________ From: Sam Cayze [[email protected]] Sent: Thursday, 9 April 2009 1:22 AM To: NT System Admin Issues Subject: RE: Memory.dmp Would a storage issue still BSOD? I have confirmation from the data center that there was certianly a blue screen on the screen for a while. -----Original Message----- From: Ken Schaefer [mailto:[email protected]] Sent: Tuesday, April 07, 2009 9:32 PM To: NT System Admin Issues Subject: RE: Memory.dmp Generally for debugging a BSOD only kernel memory is important. A kernel dump is usually around 800MB or so (max). You do not need a full dump, nor do you need a 4GB page file. Just configure something around the 1GB mark (for the purposes of capturing these dumps). Only configure a full dump if you've got someone debugging these dumps that requests it. You should always be getting a minidump file (even if you have kernel or full selected). If you are getting no minidump files then you have a problem like storage controller driver problems (which prevent writing to hard disk) or power issues (which would result in no dump files) etc. Cheers Ken ________________________________________ From: Kurt Buff [[email protected]] Sent: Wednesday, 8 April 2009 9:43 AM To: NT System Admin Issues Subject: Re: Memory.dmp RAM plus, IIRC, 2mbytes, though it might be a bit more. 1.5xRAM is wayyyyy safe. On Tue, Apr 7, 2009 at 16:39, Sam Cayze <[email protected]> wrote: > I can't find anywhere if it's the initial size, or the max size that > has to be larger than the RAM? > > Don't recall ever changing the page file settings on this box (or > anywhere). I'm not well versed in page file technology. > > > > -----Original Message----- > From: Ben Scott [mailto:[email protected]] > Sent: Tuesday, April 07, 2009 6:32 PM > To: NT System Admin Issues > Subject: Re: Memory.dmp > > On Tue, Apr 7, 2009 at 5:44 PM, Sam Cayze <[email protected]> > wrote: >> I think the Page File might have been too small :( > > That will do it. To get a full memory dump, a page file has to be on > the System Drive (the drive containing Windows), and that page file > has to be at least the size of RAM plus a few MB extra for dump metadata. > > -- Ben > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
