Continuous BSODs after clean installs

I have a Dell Inspiron 1720 laptop. I am currently on the third clean install of Vista. I only recently did the last one after my system stopped booting completely. Only a couple weeks later, I started to have BSOD crashes.
Below is the error details from the most recent crash:

Problem signature:
Problem Event Name: BlueScreen
OS Version: 6.0.6001.2.1.0.768.3
Locale ID: 1033

Additional information about the problem:
BCCode: 50
BCP1: FCA00008
BCP2: 00000001
BCP3: 81A91D30
BCP4: 00000000
OS Version: 6_0_6001
Service Pack: 1_0
Product: 768_1

Files that help describe the problem:
C:\Windows\Minidump\Mini041009-01.dmp
C:\Users\Alix\AppData\Local\Temp\WER-19843-0.sysdata.xml
C:\Users\Alix\AppData\Local\Temp\WER72CE.tmp.version.txt


I downloaded windows debugger tools and debugged the crash dump file, but it doesn't really mean much to me other than it says that the win32k.sys file is corrupt. I've posted the full debug details below.
Is there some way to find out what program or driver is causing these crashes even after brand new installs?
Is there a way to repair my currently corrupt win32k.sys file without doing a fresh install?


Loading Dump File [C:\Windows\Minidump\Mini041009-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path. *
* Use .symfix to have the debugger choose a symbol path. *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is:
*********************************************************************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
*********************************************************************
Unable to load image \SystemRoot\system32\ntkrnlpa.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntkrnlpa.exe
*** ERROR: Module load completed but symbols could not be loaded for ntkrnlpa.exe
Windows Server 2008/Windows Vista Kernel Version 6001 (Service Pack 1) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Machine Name:
Kernel base = 0x81a3e000 PsLoadedModuleList = 0x81b55c70
Debug session time: Fri Apr 10 10:32:26.036 2009 (GMT-7)
System Uptime: 0 days 0:11:35.898
*********************************************************************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
*********************************************************************
Unable to load image \SystemRoot\system32\ntkrnlpa.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntkrnlpa.exe
*** ERROR: Module load completed but symbols could not be loaded for ntkrnlpa.exe
Loading Kernel Symbols
...............................................................
................................................................
........................
Loading User Symbols
Loading unloaded module list
...
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 50, {fca00008, 1, 81a91d30, 0}

*** WARNING: Unable to verify timestamp for win32k.sys
*** ERROR: Module load completed but symbols could not be loaded for win32k.sys
***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*********************************************************************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
*********************************************************************
*********************************************************************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
*********************************************************************
Probably caused by : win32k.sys ( win32k+dbb77 )

Followup: MachineOwner
---------

0: kd> "!analyze -v "
^ Syntax error in '"!analyze -v "'
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

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: fca00008, memory referenced.
Arg2: 00000001, value 0 = read operation, 1 = write operation.
Arg3: 81a91d30, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000000, (reserved)

Debugging Details:
------------------

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*********************************************************************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
*********************************************************************
*********************************************************************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
*********************************************************************

ADDITIONAL_DEBUG_TEXT:
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols.

MODULE_NAME: win32k

FAULTING_MODULE: 81a3e000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 498f9e9d

WRITE_ADDRESS: unable to get nt!MmSpecialPoolStart
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPoolCodeStart
unable to get nt!MmPoolCodeEnd
fca00008

FAULTING_IP:
nt+53d30
81a91d30 ?? ???

MM_INTERNAL_CODE: 0

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x50

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 81a98b54 to 81ae30f5

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
b5e0e7dc 81a98b54 00000001 fca00008 00000000 nt+0xa50f5
b5e0e7f4 81a91d30 badb0d00 000005a0 0000ae6d nt+0x5ab54
b5e0e89c 94f6bb77 b5e0eb5c 00000001 fca00008 nt+0x53d30
b5e0ea3c 94f6b767 94f704b0 b5e0eb5c 00000000 win32k+0xdbb77
b5e0eaa8 94f6b3a2 ffa7d008 00000000 00000000 win32k+0xdb767
b5e0eb08 94f6b527 fd023618 b5e0eb6c b5e0eb5c win32k+0xdb3a2
b5e0ebb0 94f5891f b5e0ed0c 0000f0f0 7ffde20c win32k+0xdb527
b5e0ed34 81a959bc 000000e6 0024eb00 0024eb18 win32k+0xc891f
b5e0ed44 77db9a94 badb0d00 0024eb00 00000000 nt+0x579bc
b5e0ed48 badb0d00 0024eb00 00000000 00000000 0x77db9a94
b5e0ed4c 0024eb00 00000000 00000000 00000000 0xbadb0d00
b5e0ed50 00000000 00000000 00000000 00000000 0x24eb00


STACK_COMMAND: kb

FOLLOWUP_IP:
win32k+dbb77
94f6bb77 ?? ???

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: win32k+dbb77

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: win32k.sys

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner
---------

You did not configure the symbol cache folder properly, or set the path correctly.

http://www.vistax64.com/software/219790-reading-bsod-crash-files.html#post1007622

Looks like it's firefox. Any ideas of what I do now other than stop using firefox?


Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\Minidump\Mini041009-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*C:\SymCache*Symbol information
Executable search path is:
Windows Server 2008/Windows Vista Kernel Version 6001 (Service Pack 1) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 6001.18145.x86fre.vistasp1_gdr.080917-1612
Machine Name:
Kernel base = 0x81a3e000 PsLoadedModuleList = 0x81b55c70
Debug session time: Fri Apr 10 10:32:26.036 2009 (GMT-7)
System Uptime: 0 days 0:11:35.898
Loading Kernel Symbols
...............................................................
................................................................
........................
Loading User Symbols
Loading unloaded module list
...
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 50, {fca00008, 1, 81a91d30, 0}

Probably caused by : win32k.sys ( win32k!vSolidFillRect1+107 )

Followup: MachineOwner
---------

0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

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: fca00008, memory referenced.
Arg2: 00000001, value 0 = read operation, 1 = write operation.
Arg3: 81a91d30, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000000, (reserved)

Debugging Details:
------------------


WRITE_ADDRESS: GetPointerFromAddress: unable to read from 81b75868
Unable to read MiSystemVaType memory at 81b55420
fca00008

FAULTING_IP:
nt!RtlFillMemoryUlong+10
81a91d30 f3ab rep stos dword ptr es:[edi]

MM_INTERNAL_CODE: 0

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x50

PROCESS_NAME: firefox.exe

CURRENT_IRQL: 0

TRAP_FRAME: b5e0e7f4 -- (.trap 0xffffffffb5e0e7f4)
ErrCode = 00000002
eax=00f0f0f0 ebx=00000352 ecx=000005a0 edx=000005a0 esi=fca00008 edi=fca00008
eip=81a91d30 esp=b5e0e868 ebp=b5e0e89c iopl=0 nv up ei pl nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010206
nt!RtlFillMemoryUlong+0x10:
81a91d30 f3ab rep stos dword ptr es:[edi]
Resetting default scope

LAST_CONTROL_TRANSFER: from 81a98b54 to 81ae30f5

STACK_TEXT:
b5e0e7dc 81a98b54 00000001 fca00008 00000000 nt!MmAccessFault+0x10a
b5e0e7dc 81a91d30 00000001 fca00008 00000000 nt!KiTrap0E+0xdc
b5e0e868 94f705b7 fca00008 00001680 00f0f0f0 nt!RtlFillMemoryUlong+0x10
b5e0e89c 94f6bb77 b5e0eb5c 00000001 fca00008 win32k!vSolidFillRect1+0x107
b5e0ea3c 94f6b767 94f704b0 b5e0eb5c 00000000 win32k!vDIBSolidBlt+0x102
b5e0eaa8 94f6b3a2 ffa7d008 00000000 00000000 win32k!EngBitBlt+0x18e
b5e0eb08 94f6b527 fd023618 b5e0eb6c b5e0eb5c win32k!GrePatBltLockedDC+0x212
b5e0ebb0 94f5891f b5e0ed0c 0000f0f0 7ffde20c win32k!GrePolyPatBltInternal+0x173
b5e0ed34 81a959bc 000000e6 0024eb00 0024eb18 win32k!NtGdiFlushUserBatch+0x404
b5e0ed44 77db9a94 badb0d00 0024eb00 00000000 nt!KiFastCallEntry+0xcc
WARNING: Frame IP not in any known module. Following frames may be wrong.
b5e0ed48 badb0d00 0024eb00 00000000 00000000 0x77db9a94
b5e0ed4c 0024eb00 00000000 00000000 00000000 0xbadb0d00
b5e0ed50 00000000 00000000 00000000 00000000 0x24eb00


STACK_COMMAND: kb

FOLLOWUP_IP:
win32k!vSolidFillRect1+107
94f705b7 8b55f4 mov edx,dword ptr [ebp-0Ch]

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: win32k!vSolidFillRect1+107

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: win32k

IMAGE_NAME: win32k.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 498f9e9d

FAILURE_BUCKET_ID: 0x50_win32k!vSolidFillRect1+107

BUCKET_ID: 0x50_win32k!vSolidFillRect1+107

Followup: MachineOwner
---------

0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

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: fca00008, memory referenced.
Arg2: 00000001, value 0 = read operation, 1 = write operation.
Arg3: 81a91d30, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000000, (reserved)

Debugging Details:
------------------


WRITE_ADDRESS: GetPointerFromAddress: unable to read from 81b75868
Unable to read MiSystemVaType memory at 81b55420
fca00008

FAULTING_IP:
nt!RtlFillMemoryUlong+10
81a91d30 f3ab rep stos dword ptr es:[edi]

MM_INTERNAL_CODE: 0

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x50

PROCESS_NAME: firefox.exe

CURRENT_IRQL: 0

TRAP_FRAME: b5e0e7f4 -- (.trap 0xffffffffb5e0e7f4)
ErrCode = 00000002
eax=00f0f0f0 ebx=00000352 ecx=000005a0 edx=000005a0 esi=fca00008 edi=fca00008
eip=81a91d30 esp=b5e0e868 ebp=b5e0e89c iopl=0 nv up ei pl nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010206
nt!RtlFillMemoryUlong+0x10:
81a91d30 f3ab rep stos dword ptr es:[edi]
Resetting default scope

LAST_CONTROL_TRANSFER: from 81a98b54 to 81ae30f5

STACK_TEXT:
b5e0e7dc 81a98b54 00000001 fca00008 00000000 nt!MmAccessFault+0x10a
b5e0e7dc 81a91d30 00000001 fca00008 00000000 nt!KiTrap0E+0xdc
b5e0e868 94f705b7 fca00008 00001680 00f0f0f0 nt!RtlFillMemoryUlong+0x10
b5e0e89c 94f6bb77 b5e0eb5c 00000001 fca00008 win32k!vSolidFillRect1+0x107
b5e0ea3c 94f6b767 94f704b0 b5e0eb5c 00000000 win32k!vDIBSolidBlt+0x102
b5e0eaa8 94f6b3a2 ffa7d008 00000000 00000000 win32k!EngBitBlt+0x18e
b5e0eb08 94f6b527 fd023618 b5e0eb6c b5e0eb5c win32k!GrePatBltLockedDC+0x212
b5e0ebb0 94f5891f b5e0ed0c 0000f0f0 7ffde20c win32k!GrePolyPatBltInternal+0x173
b5e0ed34 81a959bc 000000e6 0024eb00 0024eb18 win32k!NtGdiFlushUserBatch+0x404
b5e0ed44 77db9a94 badb0d00 0024eb00 00000000 nt!KiFastCallEntry+0xcc
WARNING: Frame IP not in any known module. Following frames may be wrong.
b5e0ed48 badb0d00 0024eb00 00000000 00000000 0x77db9a94
b5e0ed4c 0024eb00 00000000 00000000 00000000 0xbadb0d00
b5e0ed50 00000000 00000000 00000000 00000000 0x24eb00


STACK_COMMAND: kb

FOLLOWUP_IP:
win32k!vSolidFillRect1+107
94f705b7 8b55f4 mov edx,dword ptr [ebp-0Ch]

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: win32k!vSolidFillRect1+107

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: win32k

IMAGE_NAME: win32k.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 498f9e9d

FAILURE_BUCKET_ID: 0x50_win32k!vSolidFillRect1+107

BUCKET_ID: 0x50_win32k!vSolidFillRect1+107

Followup: MachineOwner
---------

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.

Run mem test
start>control Panel>classic view> admin tools> memory test

What does this mean:
"This cannot be protected by try-except,
it must be protected by a Probe."

I don't think Firefox has anything to do with it. Firefox is a user-mode app. This is a Win32k (GDI) rendering issue, caused either by a hardware fault or interference from another kernel-mode driver.

win32k!vSolidFillRect1 called nt!RtlFillMemoryUlong to, uh, fill some memory, and that resulted in an attempt to write to 0xfca00008 which is not in non-paged pool on your machine, and hence the BSoD 0x50. Those window-drawing win32k.sys functions get called millions of times per day on every machine, and when you've got a crash in one of them it's almost certainly the result of bad data being passed in from another driver, pool corruption, or mangled hardware.

"This cannot be protected by try-except, it must be protected by a Probe." - That's advice to driver writers on how to avoid triggering 0x50 bugchecks, and it's immaterial in this instance. It's basically saying "you cannot hope to 'try' and see whether this memory is accessible, because that will crash the machine, and you must therefore rely on this other mechanism called a 'probe'". Don't worry about that stuff. It's got nothing to do with your specific crash.

Suggestions:

- Run the memory tests like Rive0108 siad. I'd give you at least a 50% chance of this being a hardware problem.

- Temporarily uninstall any and all "remote control" utilities you may have added. VNC, PC Anywhere... anything that attempts to "scrape" your screen and allow it to be sent as a picture across the network.

- If you're overclocking or undercooling, please don't, at least not while you're seeking BSOD assistance

- If the stuff above doesn't help, add the PoolTag and PoolTagOverruns registry values as per this KB article:

How to use the special pool feature to isolate pool damage

That'll enable a mechanism called "special pool" which might catch a pool-corruptor driver the next time it does something bad (a different BSOD which is more useful from a troubleshooting perspective).

Thanks. I ran memory tests when my system crashed the last time but I'll do it again.

I don't have any remote utilities and i'm not over or underclocking

I'll try that "special pool thing" if I still have problems after the memtest

H2SO4 said:

I don't think Firefox has anything to do with it. Firefox is a user-mode app. This is a Win32k (GDI) rendering issue, caused either by a hardware fault or interference from another kernel-mode driver.

win32k!vSolidFillRect1 called nt!RtlFillMemoryUlong to, uh, fill some memory, and that resulted in an attempt to write to 0xfca00008 which is not in non-paged pool on your machine, and hence the BSoD 0x50. Those window-drawing win32k.sys functions get called millions of times per day on every machine, and when you've got a crash in one of them it's almost certainly the result of bad data being passed in from another driver, pool corruption, or mangled hardware.

"This cannot be protected by try-except, it must be protected by a Probe." - That's advice to driver writers on how to avoid triggering 0x50 bugchecks, and it's immaterial in this instance. It's basically saying "you cannot hope to 'try' and see whether this memory is accessible, because that will crash the machine, and you must therefore rely on this other mechanism called a 'probe'". Don't worry about that stuff. It's got nothing to do with your specific crash.

Suggestions:

- Run the memory tests like Rive0108 siad. I'd give you at least a 50% chance of this being a hardware problem.

- Temporarily uninstall any and all "remote control" utilities you may have added. VNC, PC Anywhere... anything that attempts to "scrape" your screen and allow it to be sent as a picture across the network.

- If you're overclocking or undercooling, please don't, at least not while you're seeking BSOD assistance

- If the stuff above doesn't help, add the PoolTag and PoolTagOverruns registry values as per this KB article:

How to use the special pool feature to isolate pool damage

That'll enable a mechanism called "special pool" which might catch a pool-corruptor driver the next time it does something bad (a different BSOD which is more useful from a troubleshooting perspective).

Click to expand...

Thanks H2SO4

No problem. I'm happier than a pig in mud talking about this sort of stuff

The memory test came up clean

lacolocho said:

The memory test came up clean

Click to expand...

add the PoolTag and PoolTagOverruns registry values as per this KB article:

How to use the special pool feature to isolate pool damage

That'll enable a mechanism called "special pool" which might catch a pool-corruptor driver the next time it does something bad (a different BSOD which is more useful from a troubleshooting perspective).

Did I do it right?

Looks good. Make sure you reboot at least once after adding those values.

42 is ASCII for the asterisk character - * - meaning all drivers are to be subjected to this extra level of scrutiny, which is a "guard page" at the end of their pool allocations in memory. If a driver attempts to write beyond its own allocation, it'll hit the guard page and BSOD immediately instead of perhaps corrupting another driver's memory silently, which is what may be happening to you now.

So I just had another BSOD. What do I do now?

You should zip up and upload that new minidump here so someone can have a look at it for you.

Now I'm getting in error when trying to degug:

"
Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\Minidump\Mini041509-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*C:\SymCache*Symbol information
Executable search path is:
"

and then at the bottom it says:
"Debuggee not connected"

Another BSOD and tried it again, looks like it finished this time:
"
Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\Minidump\Mini041509-03.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*C:\SymCache*Symbol information
Executable search path is:
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntkrpamp.exe -
Windows Server 2008/Windows Vista Kernel Version 6001 (Service Pack 1) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 6001.18226.x86fre.vistasp1_gdr.090302-1506
Machine Name:
Kernel base = 0x81c49000 PsLoadedModuleList = 0x81d60c70
Debug session time: Wed Apr 15 21:28:28.326 2009 (GMT-7)
System Uptime: 0 days 8:02:28.128
"

more:
" ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
***
Probably caused by : mfehidk.sys ( mfehidk+1a377 )
"

"
ADDITIONAL_DEBUG_TEXT:
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols.

MODULE_NAME: mfehidk

FAULTING_MODULE: 81c49000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 46c47281

BUGCHECK_STR: 0xC1_23

SPECIAL_POOL_CORRUPTION_TYPE: 23

CUSTOMER_CRASH_COUNT: 3

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 81ce0a53 to 81d160e3

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
8535963c 81ce0a53 000000c1 87c06c90 87c0609a nt!KeBugCheckEx+0x1e
85359734 81d36f78 87c06c90 00000723 85359810 nt!NtFreeVirtualMemory+0x5d9c
8535979c 81d363ae 87c06c90 00000000 853597b8 nt!ExFreePoolWithTag+0xeb
853597ac 84a1beb7 87c06c90 853597e0 84aaaaf6 nt!ExFreePool+0xf
853597b8 84aaaaf6 84a45d40 87c06c90 00000000 Ntfs!ExFreeToPagedLookasideList+0x1e
853597e0 84a1fe14 9f06cee8 85359810 8535981a Ntfs!NtfsDeleteFcb+0x2b1
85359834 84a95ce0 9f06cee8 89786498 87c06c90 Ntfs!NtfsTeardownFromLcb+0x250
85359884 84a1dbde 9f06cee8 87c06d80 01c06f20 Ntfs!NtfsTeardownStructures+0xed
853598ac 84a9bb66 9f06cee8 87c06d80 87c06f20 Ntfs!NtfsDecrementCloseCounts+0xad
8535990c 84aaa1d4 9f06cee8 87c06d80 87c06c90 Ntfs!NtfsCommonClose+0x4da
853599a0 84a80171 89786498 0191d109 85359ac8 Ntfs!NtfsFspClose+0x117
85359a30 84a2f290 85359ac8 89786498 00000001 Ntfs!NtfsFlushVolume+0x6c
85359a88 84a2f503 85359ac8 89786498 0191d709 Ntfs!NtfsCheckpointVolumeUntilDone+0x30
85359c30 81d04fd3 8cd1af08 b6556e28 b6556e28 Ntfs!NtfsFsdShutdown+0x197
85359c48 846f9d81 8cddaeb0 8cd1af08 81d7dd70 nt!IofCallDriver+0x64
85359c74 81d04fd3 8cddaeb0 b6556e28 b6556e28 fltmgr!FltpDispatch+0xdf
85359c8c 9529c377 c44b0a08 c44b0a08 8cddaeb0 nt!IofCallDriver+0x64
85359cb0 81d04fd3 c44b0a08 b6556e28 00000000 mfehidk+0x1a377
85359cc8 81f193a7 85772d78 00000000 81d4b100 nt!IofCallDriver+0x64
85359cf8 81f19284 81d4b100 85772d78 00000000 nt!RtlCompressBuffer+0x1ef2
85359d2c 81f1ed5b 00000001 85772d78 81d56bd0 nt!RtlCompressBuffer+0x1dcf
85359d44 81c81445 00000000 00000000 85772d78 nt!MmAdjustWorkingSetSize+0x23e4
85359d7c 81e1eb18 00000000 f3f58307 00000000 nt!KeQuerySystemTime+0x14d
85359dc0 81c77a2e 81c81348 00000000 00000000 nt!RtlDestroyAtomTable+0x4fe
00000000 00000000 00000000 00000000 00000000 nt!RtlSubAuthorityCountSid+0x3c4


STACK_COMMAND: kb

FOLLOWUP_IP:
mfehidk+1a377
9529c377 ?? ???

SYMBOL_STACK_INDEX: 11

SYMBOL_NAME: mfehidk+1a377

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: mfehidk.sys

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner
---------

"

Note that the stop code is different now with special pool enabled:

0xC1: SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION

The debugger has already told you who it sees as the culprit:

IMAGE_NAME: mfehidk.sys

The reason it thinks the mfehidk.sys symbols are wrong is because that's a McAfee driver. Try updating the McAfee package.