Jared44

No, the trace analysis will not work. Memory tests indictae an issue? Which memory tests? Most likely bad RAM, is it under warranty? I suggest memtest86+ if you haven't tried to do so already.

Is it possible for us to get a dump file? I'd recommend trying to use SP3 if possible.

Okay, any other problems don't hesitate to post back.

BugCheck CD, {a0e55000, 0, 8303b2a0, 0}This bugcheck indicates a driver allocated a specific number of memory but referenced more bytes thna was allocated. 0: kd> .trap 0xffffffffe005f80cErrCode = 00000000eax=51510031 ebx=00000014 ecx=00000005 edx=00000000 esi=a0e54ff8 edi=d10f5008eip=8303b2a0 esp=e005f880 ebp=e005f888 iopl=0 nv up ei ng nz ac po cycs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010293nt!memmove+0x120:8303b2a0 8b448ef4 mov eax,dword ptr [esi+ecx*4-0Ch] ds:0023:a0e55000=????????We can see a move operation taking place, a dword value stored in the eax register was being moved to a memory location calculated by adding the esi and ecx registers, then multiplying it by 4. This results in memory write to a0e55000 which is more bytes than allocated. 0: kd> !pte a0e55000 VA a0e55000PDE at C0602838 PTE at C05072A8contains 0000000073825863 contains 0000000200000000pfn 73825 ---DA--KWEV not valid PageFile: 0 Offset: 2 Protect: 0Here we can see the address was invalid, this is because it wasn't present in memory was it wasn't allocated. 0: kd> dc a0e55000a0e55000 ???????? ???????? ???????? ???????? ????????????????a0e55010 ???????? ???????? ???????? ???????? ????????????????a0e55020 ???????? ???????? ???????? ???????? ????????????????a0e55030 ???????? ???????? ???????? ???????? ????????????????a0e55040 ???????? ???????? ???????? ???????? ????????????????a0e55050 ???????? ???????? ???????? ???????? ????????????????a0e55060 ???????? ???????? ???????? ???????? ????????????????a0e55070 ???????? ???????? ???????? ???????? ????????????????Yep, no memory addresses present. e005f7f4 83042aa8 00000000 a0e55000 00000000 nt!MmAccessFault+0x104e005f7f4 8303b2a0 00000000 a0e55000 00000000 nt!KiTrap0E+0xdce005f888 b23ee31c d10f5008 a0e54ff8 00000014 nt!memmove+0x120WARNING: Stack unwind information not available. Following frames may be wrong.e005f8b4 b23f1f49 b3100898 a0e54ff8 a4d60e30 vsergps+0x331ce005f8dc 833336c3 b31007e0 00000000 b30fe3e0 vsergps+0x6f49e005f900 83038bd5 00000000 82aa0008 b31007e0 nt!IovCallDriver+0x258e005f914 b2d7c61f e9a1f378 00000000 82aa0008 nt!IofCallDriver+0x1be005f928 b2d7c6e7 00000000 01aa0008 82aa0008 serenum!Serenum_DispatchPassThrough+0x65e005f950 833336c3 b30fe328 b31007e0 d33154f8 serenum!Serenum_CreateClose+0xa5e005f974 83038bd5 00000000 d3315554 b30fe328 nt!IovCallDriver+0x258e005f988 83248516 cab224b1 e005fb30 00000000 nt!IofCallDriver+0x1be005fa60 83227d2e b31007e0 a5df8378 bf5c6d20 nt!IopParseDevice+0xee6e005fadc 83238157 00000000 e005fb30 00000040 nt!ObpLookupObjectName+0x4fae005fb38 8322ec35 001eebc0 85df8378 83042a01 nt!ObOpenObjectByName+0x165e005fbb4 832524b4 001eec1c 80100080 001eebc0 nt!IopCreateFile+0x673e005fc00 8303f8c6 001eec1c 80100080 001eebc0 nt!NtCreateFile+0x34e005fc00 775a70f4 001eec1c 80100080 001eebc0 nt!KiSystemServicePostCall001eec24 00000000 00000000 00000000 00000000 0x775a70f4vsergps.sys may not actually be the cause but it's likely. 0: kd> lm vm vsergpsstart end module nameb23eb000 b2400000 vsergps (no symbols) Loaded symbol image file: vsergps.sys Image path: \SystemRoot\system32\DRIVERS\vsergps.sys Image name: vsergps.sys Timestamp: Wed Jul 29 11:37:36 2009 (4A702670) CheckSum: 00020B18 ImageSize: 00015000 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4I'm struggling to find anything on the driver apart from the timestamp, there's absolutely nothing coming up from google regarding this. If you know what it is then update that software, can you also tell us the program name.

Ah sorry about that, I forgot about asking him to enable Driver Verifier. What is Driver Verifier? Driver Verifier monitors Windows kernel-mode drivers, graphics drivers, and even 3rd party drivers to detect illegal function calls or actions that might corrupt the system. Driver Verifier can subject the Windows drivers to a variety of stresses and tests to find improper behavior. Essentially, if there's a 3rd party driver believed to be causing the issues at hand, enabling Driver Verifier will help us see which specific driver is causing the problem. Before enabling Driver Verifier, it is recommended to create a System Restore Point: Vista - START | type rstrui - create a restore point Windows 7 - START | type create | select "Create a Restore Point" How to enable Driver Verifier: Start > type "verifier" without the quotes > Select the following options - 1. Select - "Create custom settings (for code developers)" 2. Select - "Select individual settings from a full list" 3. Check the following boxes - - Special Pool - Pool Tracking - Force IRQL Checking - Deadlock Detection - Security Checks (Windows 7 & 8/8.1) - DDI compliance checking (Windows 8/8.1) - Miscellaneous Checks 4. Select - "Select driver names from a list" 5. Click on the "Provider" tab. This will sort all of the drivers by the provider. 6. Check EVERY box that is NOT provided by Microsoft / Microsoft Corporation. 7. Click on Finish. 8. Restart. Important information regarding Driver Verifier: - If Driver Verifier finds a violation, the system will BSOD. To expand on this a bit more for the interested, specifically what Driver Verifier actually does is it looks for any driver making illegal function calls, causing memory leaks, etc. When and/if this happens, system corruption occurs if allowed to continue. When Driver Verifier is enabled per my instructions above, it is monitoring all 3rd party drivers (as we have it set that way) and when it catches a driver attempting to do this, it will quickly flag that driver as being a troublemaker, and bring down the system safely before any corruption can occur. - After enabling Driver Verifier and restarting the system, depending on the culprit, if for example the driver is on start-up, you may not be able to get back into normal Windows because Driver Verifier will detect it in violation almost straight away, and as stated above, that will cause / force a BSOD. If this happens, do not panic, do the following: - Boot into Safe Mode by repeatedly tapping the F8 key during boot-up. - Once in Safe Mode - Start > Search > type "cmd" without the quotes. - To turn off Driver Verifier, type in cmd "verifier /reset" without the quotes. Restart and boot into normal Windows. If your OS became corrupt or you cannot boot into Windows after disabling verifier via Safe Mode: - Boot into Safe Mode by repeatedly tapping the F8 key during boot-up. - Once in Safe Mode - Start > type "system restore" without the quotes. - Choose the restore point you created earlier. -- Note that Safe Mode for Windows 8/8.1 is a bit different, and you may need to try different methods: 5 Ways to Boot into Safe Mode in Windows 8 & Windows 8.1 How long should I keep Driver Verifier enabled for? I recommend keeping it enabled for at least 24 hours. If you don't BSOD by then, disable Driver Verifier. I will usually say whether or not I'd like for you to keep it enabled any longer. My system BSOD'd with Driver Verifier enabled, where can I find the crash dumps? - If you have the system set to generate Small Memory Dumps, they will be located in %systemroot%\Minidump. - If you have the system set to generate Kernel-Memory Dumps, it will be located in %systemroot% and labeled MEMORY.DMP.

I just thought I'd add a little bit. BAD_POOL_HEADER (19)The pool is already corrupt at the time of the current request.This may or may not be due to the caller.The internal pool links must be walked to figure out a possible cause ofthe problem, and then special pool applied to the suspect tags or the driververifier to a suspect driver.Arguments:Arg1: 00000020, a pool block header size is corrupt.Arg2: c42da2e8, The pool entry we were looking for within the page.Arg3: c42da468, The next pool entry.Arg4: 1830000b, (reserved)So here we can see the pool entry we were looking for within the pool page and the next pool entry that should use this current pool. 0: kd> !pool c42da2e8Pool page c42da2e8 region is Nonpaged pool c42da000 size: b8 previous size: 0 (Allocated) File (Protected) c42da0b8 size: 8 previous size: b8 (Free) .... c42da0c0 size: 68 previous size: 8 (Allocated) FMsl c42da128 size: 168 previous size: 68 (Allocated) CcSc c42da290 size: 58 previous size: 168 (Allocated) SAds*c42da2e8 size: 180 previous size: 58 (Free ) *Io Process: 8bedc030 Pooltag Io : general IO allocations, Binary : nt!ioc42da468 doesn't look like a valid small pool allocation, checking to seeif the entire page is actually part of a large page allocation...c42da468 is not a valid large pool allocation, checking large session pool...c42da468 is not valid pool. Checking for freed (or corrupt) poolBad previous allocation size @c42da468, last size was 30****** An error (or corruption) in the pool was detected;*** Attempting to diagnose the problem.****** Use !poolval c42da000 for more details.Pool page [ c42da000 ] is __inVALID.Analyzing linked list...[ c42da2e8 --> c42da5c8 (size = 0x2e0 bytes)]: Corrupt regionScanning for single bit errors...None foundHere we can see the linked list for the pool is corrupt, but the end of the list is with the next pool entry. That is wrong, remember if we look back the next list entry should be c42da468 not c42da5c8 the cause is probably due to a driver overwriting the pool block. 0: kd> dt nt!_POOL_HEADER c42da2e8 +0x000 PreviousSize : 0y000001011 (0xb) +0x000 PoolIndex : 0y0000000 (0) +0x002 BlockSize : 0y000110000 (0x30) +0x002 PoolType : 0y0001100 (0xc) +0x000 Ulong1 : 0x1830000b +0x004 PoolTag : 0x20206f49 +0x004 AllocatorBackTraceIndex : 0x6f49 +0x006 PoolTagHash : 0x2020This is the pool allocation information which we were looking at. 0: kd> dt nt!_POOL_HEADER c42da468 +0x000 PreviousSize : 0y101010000 (0x150) +0x000 PoolIndex : 0y0100011 (0x23) +0x002 BlockSize : 0y101010011 (0x153) +0x002 PoolType : 0y0100000 (0x20) +0x000 Ulong1 : 0x41534750 +0x004 PoolTag : 0x332c412c +0x004 AllocatorBackTraceIndex : 0x412c +0x006 PoolTagHash : 0x332cThis pool is clearly corrupt as it's header has been overwritten. A full memory dump would be needed to see what is being ran in user mode but MapPoint isn't necessarily the cause just because it's in the stack.

I kind of said it wrong. It depends on the CPU of course and whether or not it supports 64bit architecture. Well, yes I was told it needed to be dual core... Don't really know why I believed that...

Hello, I currently have a blog if anyone is interested. It involves BSOD debugging but also some Windows Internals as well, they mix together so it's all good stuff. If anyone is interested then here's the link: http://bsoddebugging.blogspot.co.uk

It also depends on the CPU, it needs to be dual core or more for the 64bit arcitecture to work. It's a lot more demanding on RAM as well so unless you're upgrading the RAM and you have a dual core CPU there is little point.

I'm new here but I'm currently on two other forums. http://www.sysnative.com/forums/members/jared.html http://www.techsupportforum.com/forums/members/jared-1030864.html I'll try and post where I can.