System crashing with driver errors

[ToonGeneral]

I have been suffering with system crahes for some time now. To be honest I was putting up with it because I couldnt be bothered to do anything about it. They have become more frequent and I should really do something about it.

I followed the information in a post on another forum in order to be able to examine the error dumps. I seem to be getting many different programs as the cause of the problem and am not sure how to proceed. These range from games to things like VLC and Outlook. I am not very experienced at debugging these sorts of problems and so I was hoping someone may be able to help.

I have included a sample of one of the crash dumps in the hope that someone can help. I can provide many more (there are currently 146 in my \Windows\Minidump folder ) if needed.

Many thanks for any possible help.

************************************************** *****************************

* *

* 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: fffe4080, memory referenced

Arg2: 00000002, IRQL

Arg3: 00000001, value 0 = read operation, 1 = write operation

Arg4: 806ee2dc, address which referenced memory

Debugging Details:

------------------

WRITE_ADDRESS: fffe4080

CURRENT_IRQL: 2

FAULTING_IP:

hal!HalpStopOhciInterrupt+5c

806ee2dc 890d8000feff mov dword ptr ds:[0FFFE0080h],ecx

CUSTOMER_CRASH_COUNT: 2

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: Civ4Warlords.ex

LAST_CONTROL_TRANSFER: from 80565674 to 806ee2dc

STACK_TEXT:

ae043cf0 80565674 00000000 00000001 00000000 hal!HalpStopOhciInterrupt+0x5c

ae043d54 804de7ec 00000054 00000000 1863fe24 nt!ObpReferenceSecurityDescriptor+0x35

ae043d64 7c90eb94 badb0d00 1863fe1c ae043d98 nt!KiUnexpectedInterrupt65+0x2

WARNING: Frame IP not in any known module. Following frames may be wrong.

ae043d68 badb0d00 1863fe1c ae043d98 ae043dcc 0x7c90eb94

ae043d6c 1863fe1c ae043d98 ae043dcc 00000000 0xbadb0d00

ae043d70 ae043d98 ae043dcc 00000000 00000000 0x1863fe1c

ae043d74 ae043dcc 00000000 00000000 00000000 0xae043d98

ae043d98 00000000 0f2d5eac 1863fd48 1863fd48 0xae043dcc

STACK_COMMAND: kb

FOLLOWUP_IP:

nt!ObpReferenceSecurityDescriptor+35

80565674 ?? ???

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt!ObpReferenceSecurityDescriptor+35

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntoskrnl.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 42250ff9

FAILURE_BUCKET_ID: 0xA_W_nt!ObpReferenceSecurityDescriptor+35

BUCKET_ID: 0xA_W_nt!ObpReferenceSecurityDescriptor+35

Followup: MachineOwner

---------

[nitroshift]

What you really have to do is setup your pc for a COMPLETE memory dump. That will tell us all we need to know. Do that and come back here with a link where you uploaded the complete memory dump for cluberti (and myself) to check it out. To create a complete memory dump, follow the instructions below:

Memory dump of the entire system:

1. Create or set the following registry value:

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters

Value: CrashOnCtrlScroll

Type: REG_DWORD

Data: 1

2. Right-Click on the "My Computer" icon on the desktop and select "Properties", then click the "Advanced tab. On the "Advanced" tab, click "Settings" under the "Performance" header. Click the "Advanced" tab, then click "Change" under "Virtual Memory". Set the pagefile to be located on the partition where the OS is installed, and set it to be equal to Physical RAM + 50 MB.

3. Also in the "System Properties" window on the "Advanced" tab, click the "Settings" buttun under the "Startup and Recovery" header. Make sure "Complete Memory Dump" is selected (see 3a if this is not in the list). You can change the location of the memory dump file to a different local partition if you do not have enough room on the partition where the OS is installed.

3a. If the "Complete Memory Dump" option in step 3 is not available, you will need to manually set this registry value:

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl

Value: CrashDumpEnabled

Type: REG_DWORD

Value: 1

4. You will need to reboot for these changes to take effect.

5. The next time that the system is exhibiting the problem you were asked to dump the machine for, hold down the RIGHT CTRL key and press the SCROLL LOCK key twice to cause the machine to bugcheck and create a memory dump. After the box comes back up, you'll find the resulting memory dump file in %systemroot%\memory.dmp that can be analyzed.

PS. The instructions belong to cluberti and all credit should go towards himself.

Edited March 14, 2007 by nitroshift

[ToonGeneral]

Thanks for the fast reply nitroshift, I've made the above changes. Couple of points though:

1.) When the system hangs it auto reboots, I'm not too sure when I am supposed to be doing right ctrl + scroll lock x2?

2.) My system is running with 3GB RAM, which will create a pretty massive dump file. Is this ok?

[nitroshift]

1. Right click on My Computer ---> Properties ---> Advanced ---> Startup and Recovery, remove the tick from the box that reads "Automatically restart".

2. You can archive it (Or take out RAM until you get to the minimum possible, depending on the size of your sticks).

EDIT:

I forgot to say Welcome to msfn

Edited March 14, 2007 by nitroshift

[cluberti]

Actually, for this error, a kernel dump will do. ToonGeneral, do you still have the kernel dump? I'd like to look at it.

[ToonGeneral]

Cheers cluberti, the 3GB page file was taking forever to upload, even rar-ed

I've PM'd you with the location of some of the kernel dumps, any help is much appreciated.

Edited March 15, 2007 by ToonGeneral

[cluberti]

These aren't even kernel dumps, they're "small" dumps, so this does change things. We will need at least a kernel dump (and a full dump, if you can get it). Here's what I can tell, at least, from the data I've got - every dump eventually shows that we're failing in a kernel-mode driver that is trying to write to a memory page that has not been allocated or initialized, but these writes are while whatever driver is causing this is at IRQ Level (IRQL) 2. That's important because anything running at L2 or higher cannot cause a fault that will invoke the scheduler, and page faulting on either a paged-out memory address to copy back into memory, or writing to an unallocated or uninitialized block, will do exactly that). When this happens, the box immediately bugchecks, because this is a no-no.

In each dump, every time we're either pointing to memory or accessing memory where a kernel-mode driver object should be, and it seems like either the nForce chipset drivers are at fault here, or your box might be running some sort of malware or rootkit - those are the only times I see this. Again, we need at least a kernel dump, and a full dump if you can, in order to narrow this down further.

That said, here's what I've found so far, for reference. All of the dumps you have basically look like this once taken apart, but they're all faulting in different kernel-mode modules, making me suspicious of possible malware (I'm somewhat paranoid about random bugchecks, you see, and these are all random enough to trigger my paranoia):

//Here, we see the stack at the time of the fault:
kd> kvn
 # ChildEBP RetAddr  Args to Child			  
00 f78ced28 804e4939 00000000 8a4cb280 8a4cba40 hal!KfLowerIrql+0xc (FPO: [0,0,0])
01 f78ced3c 804e68da 00000000 00000001 00000000 nt!KeReleaseMutant+0xbb (FPO: [Non-Fpo])
02 f78ced54 b1ddc0c4 8a4cba40 00000000 8a4cbbbc nt!KeReleaseMutex+0x14 (FPO: [Non-Fpo])
WARNING: Stack unwind information not available. Following frames may be wrong.
03 00000000 00000000 00000000 00000000 00000000 nvapu+0x160c4

//Next, we check to see if we're in kernel mode or user mode:
kd> dg nvapu
								  P Si Gr Pr Lo
Sel	Base	 Limit	 Type	l ze an es ng Flags
---- -------- -------- ---------- - -- -- -- -- --------
B1DC6000 00000000 ffffffff Code RE Ac 0 Bg Pg P  Nl 00000c9b
//The PL number is 0 (hard to see here, but it is), which means the cs register tells us we're in kernel mode

//Let's look at the registers for the KfLowerIrql frame:
kd> r
eax=00000000 ebx=8a4cba00 ecx=00000000 edx=00000000 esi=8a4cba40 edi=8abf5b30
eip=806ee2dc esp=f78ced2c ebp=f78ced3c iopl=0		 nv up ei pl zr na pe nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000			 efl=00210246
hal!KfLowerIrql+0xc:
806ee2dc 890d8000feff	mov	 dword ptr ds:[0FFFE0080h],ecx ds:0023:fffe0080=????????

//cs says we've got full privs, and all registers seem to be OK, so let's unassemble this:
kd> u hal!KfLowerIrql
hal!KfLowerIrql:
806ee2d0 33c0			xor	 eax,eax
806ee2d2 8ac1			mov	 al,cl
806ee2d4 33c9			xor	 ecx,ecx
806ee2d6 8a8858e26e80	mov	 cl,byte ptr hal!HalpIRQLtoTPR (806ee258)[eax]
806ee2dc 890d8000feff	mov	 dword ptr ds:[0FFFE0080h],ecx
806ee2e2 a18000feff	  mov	 eax,dword ptr ds:[FFFE0080h]
806ee2e7 c3			  ret
hal!KeGetCurrentIrql:
806ee2e8 a18000feff	  mov	 eax,dword ptr ds:[FFFE0080h]

//We know that the address that referenced the memory was 806ee2dc from the bugcheck code, so that means that this is the instruction we were executing when we bugchecked:
806ee2dc 890d8000feff	mov	 dword ptr ds:[0FFFE0080h],ecx

//According to IA32 processor Spec, FFFE0080 is the address of TPR register of Local APIC, NT uses TPR to manage its own interrupt priority which is independent of hardware priority.  From what I can tell, we're done lowering the IRQ Level and are finishing cleaning up our locals and variables:

kd> x nt!K*Apc*
804e5287 nt!KeInitializeApc = <no type information>
80516463 nt!KeAreApcsDisabled = <no type information>
805593f8 nt!KeUserApcDispatcher = <no type information>
804e5411 nt!KeInsertQueueApc = <no type information>
804f9ea4 nt!KeDisableApcQueuingThread = <no type information>
80533f6a nt!KeVdmInsertQueueApc = <no type information>
8050692d nt!KeRemoveQueueApc = <no type information>
804db828 nt!KiSwapContext = <no type information>
804eb869 nt!KiMoveApcState = <no type information>
804e5379 nt!KiInsertQueueApc = <no type information>
804e61f4 nt!KiInitializeUserApc = <no type information>
804e52dd nt!KiDeliverApc = <no type information>
804f9e3a nt!KeFlushQueueApc = <no type information>
kd> dt nt!_KAPC
   +0x000 Type			 : Int2B
   +0x002 Size			 : Int2B
   +0x004 Spare0		   : Uint4B
   +0x008 Thread		   : Ptr32 _KTHREAD
   +0x00c ApcListEntry	 : _LIST_ENTRY
   +0x014 KernelRoutine	: Ptr32	
   +0x018 RundownRoutine   : Ptr32	
   +0x01c NormalRoutine	: Ptr32	
   +0x020 NormalContext	: Ptr32 Void
   +0x024 SystemArgument1  : Ptr32 Void
   +0x028 SystemArgument2  : Ptr32 Void
   +0x02c ApcStateIndex	: Char
   +0x02d ApcMode		  : Char
   +0x02e Inserted		 : UChar
kd> dt nt!_KTHREAD
   +0x000 Header		   : _DISPATCHER_HEADER
   +0x010 MutantListHead   : _LIST_ENTRY
   +0x018 InitialStack	 : Ptr32 Void
   +0x01c StackLimit	   : Ptr32 Void
   +0x020 Teb			  : Ptr32 Void
   +0x024 TlsArray		 : Ptr32 Void
   +0x028 KernelStack	  : Ptr32 Void
   +0x02c DebugActive	  : UChar
   +0x02d State			: UChar
   +0x02e Alerted		  : [2] UChar
   +0x030 Iopl			 : UChar
   +0x031 NpxState		 : UChar
   +0x032 Saturation	   : Char
   +0x033 Priority		 : Char
   +0x034 ApcState		 : _KAPC_STATE
   +0x04c ContextSwitches  : Uint4B
   +0x050 IdleSwapBlock	: UChar
   +0x051 Spare0		   : [3] UChar
   +0x054 WaitStatus	   : Int4B
   +0x058 WaitIrql		 : UChar
   +0x059 WaitMode		 : Char
   +0x05a WaitNext		 : UChar
   +0x05b WaitReason	   : UChar
   +0x05c WaitBlockList	: Ptr32 _KWAIT_BLOCK
   +0x060 WaitListEntry	: _LIST_ENTRY
   +0x060 SwapListEntry	: _SINGLE_LIST_ENTRY
   +0x068 WaitTime		 : Uint4B
   +0x06c BasePriority	 : Char
   +0x06d DecrementCount   : UChar
   +0x06e PriorityDecrement : Char
   +0x06f Quantum		  : Char
   +0x070 WaitBlock		: [4] _KWAIT_BLOCK
   +0x0d0 LegoData		 : Ptr32 Void
   +0x0d4 KernelApcDisable : Uint4B
   +0x0d8 UserAffinity	 : Uint4B
   +0x0dc SystemAffinityActive : UChar
   +0x0dd PowerState	   : UChar
   +0x0de NpxIrql		  : UChar
   +0x0df InitialNode	  : UChar
   +0x0e0 ServiceTable	 : Ptr32 Void
   +0x0e4 Queue			: Ptr32 _KQUEUE
   +0x0e8 ApcQueueLock	 : Uint4B
   +0x0f0 Timer			: _KTIMER
   +0x118 QueueListEntry   : _LIST_ENTRY
   +0x120 SoftAffinity	 : Uint4B
   +0x124 Affinity		 : Uint4B
   +0x128 Preempted		: UChar
   +0x129 ProcessReadyQueue : UChar
   +0x12a KernelStackResident : UChar
   +0x12b NextProcessor	: UChar
   +0x12c CallbackStack	: Ptr32 Void
   +0x130 Win32Thread	  : Ptr32 Void
   +0x134 TrapFrame		: Ptr32 _KTRAP_FRAME
   +0x138 ApcStatePointer  : [2] Ptr32 _KAPC_STATE
   +0x140 PreviousMode	 : Char
   +0x141 EnableStackSwap  : UChar
   +0x142 LargeStack	   : UChar
   +0x143 ResourceIndex	: UChar
   +0x144 KernelTime	   : Uint4B
   +0x148 UserTime		 : Uint4B
   +0x14c SavedApcState	: _KAPC_STATE
   +0x164 Alertable		: UChar
   +0x165 ApcStateIndex	: UChar
   +0x166 ApcQueueable	 : UChar
   +0x167 AutoAlignment	: UChar
   +0x168 StackBase		: Ptr32 Void
   +0x16c SuspendApc	   : _KAPC
   +0x19c SuspendSemaphore : _KSEMAPHORE
   +0x1b0 ThreadListEntry  : _LIST_ENTRY
   +0x1b8 FreezeCount	  : Char
   +0x1b9 SuspendCount	 : Char
   +0x1ba IdealProcessor   : UChar
   +0x1bb DisableBoost	 : UChar
kd> dt nt!_KAPC_STATE
   +0x000 ApcListHead	  : [2] _LIST_ENTRY
   +0x010 Process		  : Ptr32 _KPROCESS
   +0x014 KernelApcInProgress : UChar
   +0x015 KernelApcPending : UChar
   +0x016 UserApcPending   : UChar
kd> uf 806ee2dc 
hal!KfLowerIrql:
806ee2d0 33c0			xor	 eax,eax
806ee2d2 8ac1			mov	 al,cl
806ee2d4 33c9			xor	 ecx,ecx
806ee2d6 8a8858e26e80	mov	 cl,byte ptr hal!HalpIRQLtoTPR (806ee258)[eax]
806ee2dc 890d8000feff	mov	 dword ptr ds:[0FFFE0080h],ecx
806ee2e2 a18000feff	  mov	 eax,dword ptr ds:[FFFE0080h]
806ee2e7 c3			  ret
kd> dt nt!_KPROCESS
   +0x000 Header		   : _DISPATCHER_HEADER
   +0x010 ProfileListHead  : _LIST_ENTRY
   +0x018 DirectoryTableBase : [2] Uint4B
   +0x020 LdtDescriptor	: _KGDTENTRY
   +0x028 Int21Descriptor  : _KIDTENTRY
   +0x030 IopmOffset	   : Uint2B
   +0x032 Iopl			 : UChar
   +0x033 Unused		   : UChar
   +0x034 ActiveProcessors : Uint4B
   +0x038 KernelTime	   : Uint4B
   +0x03c UserTime		 : Uint4B
   +0x040 ReadyListHead	: _LIST_ENTRY
   +0x048 SwapListEntry	: _SINGLE_LIST_ENTRY
   +0x04c VdmTrapcHandler  : Ptr32 Void
   +0x050 ThreadListHead   : _LIST_ENTRY
   +0x058 ProcessLock	  : Uint4B
   +0x05c Affinity		 : Uint4B
   +0x060 StackCount	   : Uint2B
   +0x062 BasePriority	 : Char
   +0x063 ThreadQuantum	: Char
   +0x064 AutoAlignment	: UChar
   +0x065 State			: UChar
   +0x066 ThreadSeed	   : UChar
   +0x067 DisableBoost	 : UChar
   +0x068 PowerState	   : UChar
   +0x069 DisableQuantum   : UChar
   +0x06a IdealNode		: UChar
   +0x06b Flags			: _KEXECUTE_OPTIONS
   +0x06b ExecuteOptions   : UChar

kd> r al
al=0
kd> r cl
cl=0
kd> u 806ee258
hal!HalpIRQLtoTPR:
806ee258 003d41415161	add	 byte ptr ds:[61514141h],bh
806ee25e 7181			jno	 hal!PicHandler+0x135 (806ee1e1)
806ee260 91			  xchg	eax,ecx
806ee261 a1b1b1b1b1	  mov	 eax,dword ptr ds:[B1B1B1B1h]
806ee266 b1b1			mov	 cl,0B1h
806ee268 b1b1			mov	 cl,0B1h
806ee26a b1b1			mov	 cl,0B1h
806ee26c b1b1			mov	 cl,0B1h

So it looks like we've walked back to zero, and are either calling back into the driver, or trying to write to an address that is invalid (not likely). We need more data!

[ToonGeneral]

Thanks for the reply cluberti, I've resumed the upload of the full 3GB dump, RAR-ed up it's only 523MB but the connection here is shocking (27K up, got dumped onto a shared usage for abusing the line, too much P2P :-s) so it'll take a while. I'll let you know.

Are there any scanners you suggest I run in the meantime? I run a full AVG sweep of all my drives every week and a daily sweep of the C: drive. I run Adaware fairly frequently but not anything more than that.

Muchos for all the help!

[cluberti]

OK, so it's not malware or a virus. It's your audio driver (looks like nForce drivers...). Here's what I've found:

//First, the stack causing the problem
kd> kvn
 # ChildEBP RetAddr  Args to Child			  
00 ab5e4b3c 806ee2dc badb0d00 00000000 ab5e4bb0 nt!KiTrap0E+0x233 (FPO: [0,0] TrapFrame @ ab5e4b3c)
01 ab5e4bac 804e4939 00000000 00000000 89b0ce00 hal!KfLowerIrql+0xc (FPO: [0,0,0])
02 ab5e4bc0 804e68da 00000000 00000001 00000000 nt!KeReleaseMutant+0xbb (FPO: [Non-Fpo])
03 ab5e4bd8 b9948fd7 b9948eb8 00000000 8a3799a0 nt!KeReleaseMutex+0x14 (FPO: [Non-Fpo])
04 ab5e4c24 b9fb0f85 8a1849d8 89b0ce00 ab5e4c58 sysaudio!CFilterInstance::FilterDispatchIoControl+0x43 (FPO: [Non-Fpo])
05 ab5e4c34 804e37f7 8a1849d8 89b0ce00 806ee2d0 ks!DispatchDeviceIoControl+0x28 (FPO: [Non-Fpo])
06 ab5e4c44 8056a101 89b0cf48 89b0ae78 89b0ce00 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
07 ab5e4c58 80579a8a 8a1849d8 89b0ce00 89b0ae78 nt!IopSynchronousServiceTail+0x60 (FPO: [Non-Fpo])
08 ab5e4d00 8057bfa5 0000034c 000002c0 00000000 nt!IopXxxControlFile+0x611 (FPO: [Non-Fpo])
09 ab5e4d34 804de7ec 0000034c 000002c0 00000000 nt!NtDeviceIoControlFile+0x2a (FPO: [Non-Fpo])
0a ab5e4d34 7c90eb94 0000034c 000002c0 00000000 nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ ab5e4d64)
0b 0012a518 7c90d8ef 7c8016be 0000034c 000002c0 ntdll!KiFastSystemCallRet (FPO: [0,0,0])
0c 0012a51c 7c8016be 0000034c 000002c0 00000000 ntdll!ZwDeviceIoControlFile+0xc (FPO: [10,0,0])
0d 0012a57c 73f1228a 0000034c 002f0003 0012a5e4 kernel32!DeviceIoControl+0x78 (FPO: [Non-Fpo])
0e 0012a5b4 73f149d4 0000034c 002f0003 0012a5e4 dsound!PostDevIoctl+0x6e (FPO: [Non-Fpo])
0f 0012a604 73f156a7 0000034c 00000002 00000012 dsound!KsGetPinProperty+0x4b (FPO: [Non-Fpo])
10 0012a638 73f158c3 0000034c 00000012 00000002 dsound!KsIsUsablePin+0x23 (FPO: [Non-Fpo])
11 0012a66c 73f1cd7f 0000034c 00000001 019021d4 dsound!KsEnumDevicePins+0x8d (FPO: [Non-Fpo])
12 0012a694 73f4f5f3 03902aa8 01902aa8 019020f0 dsound!CKsDevice::Initialize+0x7a (FPO: [Non-Fpo])
13 0012a6ac 73f1d6d2 01902aa8 00000000 019021f0 dsound!CKsCaptureDevice::Initialize+0x18 (FPO: [Non-Fpo])

//We know the bugcheck was a STOP 0xA, so analyze -v gives us the arguments we need to troubleshoot:
Arguments:
Arg1: fffe4080, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: 806ee2dc, address which referenced memory

//We know that we were at IRQL Dispatch, and we were doing a write operation (writing to a memory page).  Since we bugchecked, and it was a write, it likely means that something accessed memory that had (for whatever reason) been paged out.  Like I said before, anything that causes a scheduler event (like a soft page fault to page in memory from the paging file) causes a STOP 0xA at IRQL2 or higher.  Let's check this out, then, and look for a page fault:

//First, the referenced address is clean, so no problems there (we haven't written yet, and there is nothing here currently - this shouldn't cause an error):
kd> dd fffe4080
fffe4080  ???????? ???????? ???????? ????????
fffe4090  ???????? ???????? ???????? ????????
fffe40a0  ???????? ???????? ???????? ????????
fffe40b0  ???????? ???????? ???????? ????????
fffe40c0  ???????? ???????? ???????? ????????
fffe40d0  ???????? ???????? ???????? ????????
fffe40e0  ???????? ???????? ???????? ????????
fffe40f0  ???????? ???????? ???????? ????????

//Next, let's check the address that referenced this memory:
kd> uf 806ee2dc
hal!KfLowerIrql:
806ee2d0 33c0			xor	 eax,eax
806ee2d2 8ac1			mov	 al,cl
806ee2d4 33c9			xor	 ecx,ecx
806ee2d6 8a8858e26e80	mov	 cl,byte ptr hal!HalpIRQLtoTPR (806ee258)[eax]
806ee2dc 890d8000feff	mov	 dword ptr ds:[0FFFE0080h],ecx
806ee2e2 a18000feff	  mov	 eax,dword ptr ds:[FFFE0080h]
806ee2e7 c3			  ret

//So we know we wrote during a KfLowerIrql call.  Going back to the Followup IP data, to see what should be pushed back once we lower the IRQL:
sysaudio!CFilterInstance::FilterDispatchIoControl+43
b9948fd7 8b75e4		  mov	 esi,dword ptr [ebp-1Ch]

//Checking registers to see if ebp-1C is correct in the esi register, and if so, what it points to:
kd> r
eax=ffdff13c ebx=00000002 ecx=00000000 edx=40000000 esi=806ee2dc edi=fffe4080
eip=804e187f esp=ab5e4b24 ebp=ab5e4b3c iopl=0		 nv up ei ng nz na pe nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000			 efl=00000286
nt!KiTrap0E+0x233:
804e187f f7457000000200  test	dword ptr [ebp+70h],20000h ss:0010:ab5e4bac=00010246

kd> r esi
esi=806ee2dc
kd> r ebp
ebp=ab5e4b3c
kd> ?1c
Evaluate expression: 28 = 0000001c
kd> ?ab5e4b3c-0000001c
Evaluate expression: -1419883744 = ab5e4b20
kd> dd ab5e4b20
ab5e4b20  804e187f 0000000a fffe4080 00000002
ab5e4b30  00000001 806ee2dc ab5e4b3c ab5e4bc0
ab5e4b40  806ee2dc badb0d00 00000000 ab5e4bb0
ab5e4b50  b9fb0e98 89b0ce00 89aa4f88 b9fb0dbf
ab5e4b60  00000000 00000000 89b0ce00 00000000
ab5e4b70  00000023 00000023 00000000 00000000
ab5e4b80  00000000 00000020 ab5e4c14 00000030
ab5e4b90  8a379790 b9948eb8 89b0ce00 ab5e4bc0
kd> dc 804e187f 
804e187f  007045f7 74000200 143d830d 0080552a  .Ep....t..=.*U..
804e188f  fe69850f 3d83ffff 805593a0 5c850f00  ..i....=..U....\
804e189f  83fffffe 559e203d 850f0080 fffffe4f  ....= .U....O...
804e18af  0000ffb8 a1a8eb00 ffdff054 f05405c7  ........T.....T.
804e18bf  0000ffdf 45890000 e9e58b68 ffffd78d  .......Eh.......
804e18cf  7045f790 00020000 45f70d75 0000016c  ..Ep....u..El...
804e18df  f9840f00 0f000000 210fc321 d7210fc9  ........!..!..!.
804e18ef  89185d89 7d891c4d db210f20 0ff1210f  .]..M..} .!..!..
kd> u 804e187f 
nt!KiTrap0E+0x233:
804e187f f7457000000200  test	dword ptr [ebp+70h],20000h
804e1886 740d			je	  nt!KiTrap0E+0x249 (804e1895)
804e1888 833d142a558000  cmp	 dword ptr [nt!KeI386VdmIoplAllowed (80552a14)],0
804e188f 0f8569feffff	jne	 nt!KiTrap0E+0xb2 (804e16fe)
804e1895 833da093558000  cmp	 dword ptr [nt!KiFreezeFlag (805593a0)],0
804e189c 0f855cfeffff	jne	 nt!KiTrap0E+0xb2 (804e16fe)
804e18a2 833d209e558000  cmp	 dword ptr [nt!KiBugCheckData (80559e20)],0
804e18a9 0f854ffeffff	jne	 nt!KiTrap0E+0xb2 (804e16fe)

//So, looks like we are pointing correctly - to the KeTrapOE pointer.  That means the problem happened at or around the sysaudio!CFilter location in the stack.  Let's see what's missing there, if anything:
kd> uf 8a1849d8
No code found, aborting

kd> dc 8a1849d8
8a1849d8  00c40003 00000000 8a2bac10 00000000  ..........+.....
8a1849e8  00000000 00000000 00000000 00002050  ............P ..
8a1849f8  00000000 00000000 8a184a90 0000002f  .........J../...
8a184a08  00000007 00000000 00000000 00000000  ................
8a184a18  00000000 00000000 00000000 00000000  ................
8a184a28  00000000 00000000 00000000 00000000  ................
8a184a38  00140014 8a184a3c 8a184a3c 00000000  ....<J..<J......
8a184a48  00000000 00000000 00000000 00000000  ................

kd> !heap 00c40003 
Index   Address  Name	  Debugging options enabled

kd> !address 00c40003 
address 00c40003 not found in any known Kernel Address Range ----

kd> uf 00c40003 
No code found, aborting

kd> ln 00c40003 

kd> dc 00c40003 
00c40003  ???????? ???????? ???????? ????????  ????????????????
00c40013  ???????? ???????? ???????? ????????  ????????????????
00c40023  ???????? ???????? ???????? ????????  ????????????????
00c40033  ???????? ???????? ???????? ????????  ????????????????
00c40043  ???????? ???????? ???????? ????????  ????????????????
00c40053  ???????? ???????? ???????? ????????  ????????????????
00c40063  ???????? ???????? ???????? ????????  ????????????????
00c40073  ???????? ???????? ???????? ????????  ????????????????

I can't say for sure what this is, but 00c40003 certainly looks like a heap location (but not in any active heaps for this process). I also don't know for sure why it's being called, but I can say it's empty and invalid (and would generate a page fault when hit, and ultimately a STOP 0xA).

If you would, upgrade your nForce driver set to the latest WHQL or WDDL version (if available) from NVidia, and see if that helps.

[nitroshift]

That means the problem happened at or around the sysaudio!CFilter location in the stack.

Am I right cluberti?

[cluberti]

Correct - there's something going on deep inside the audio driver that we can't see here. The sysaudio call is a system call to play a sound on the default sound device, but the heap pointer is invalid. It's not anywhere near the heap ranges in the dump (you can see the ranges with permutations of the !heap command), and if we really are trying to use this heap handle, we're going to bugcheck.

[cluberti]

ToonGeneral, any luck after updating the nForce drivers?

[ToonGeneral]

Hi guys, sorry for taking a while to respond after you had put in so much effort helping me to track the problem down.

I was already running the latest drivers for both the nForce chipset (5.10) and my nvidia FX5950 (93.71) according to the nvidia site. I have just spent some time this morning running the nvidia un-installer to remove all the drivers and then re-installing them with the latest drivers downloaded from the site. I don't think this will have solved my problem as it has not fixed the issue with my onboard S/PDIF which had recently stopped working (the crashes pre-date this, altho obv they could be symptoms of the same issue).

I will continue compiling error reports if the crashes continue. I'm assuming that the drivers of the nvidia site are the ones I should be using?!?

Cheers again for all your assistance.