bsod in inspect.sys

Just got a BSOD in inspect.sys with latest version of Comodo (2.4.16.174). Don’t know why it happened, I have had it installed since it was released and this was the first time I got BSOD with this version (earlier betas caused BSOD at every startup, but this is fixed now!). Attaching the minidump file. Anyone know what caused this???

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

Symbol search path is: SRVc:\websymbolsSymbol information
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86 compatible
Product: WinNt
Built by: 2600.xpsp_sp2_gdr.050301-1519
Kernel base = 0x804d7000 PsLoadedModuleList = 0x805624a0
Debug session time: Fri Feb 2 20:13:29.015 2007 (GMT+1)
System Uptime: 3 days 20:12:23.606
Loading Kernel Symbols

Loading User Symbols
Loading unloaded module list


  •                                                                         *
    
  •                    Bugcheck Analysis                                    *
    
  •                                                                         *
    

Use !analyze -v to get detailed debugging information.

BugCheck D1, {0, 2, 1, f78e9e12}

Unable to load image inspect.sys, Win32 error 2
*** WARNING: Unable to verify timestamp for inspect.sys
*** ERROR: Module load completed but symbols could not be loaded for inspect.sys
Probably caused by : inspect.sys ( inspect+8e12 )

Followup: MachineOwner

0: kd> !analyze -v


  •                                                                         *
    
  •                    Bugcheck Analysis                                    *
    
  •                                                                         *
    

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: 00000000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: f78e9e12, address which referenced memory

Debugging Details:

WRITE_ADDRESS: 00000000

CURRENT_IRQL: 2

FAULTING_IP:
inspect+8e12
f78e9e12 ?? ???

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

TRAP_FRAME: 80555ed0 – (.trap ffffffff80555ed0)
ErrCode = 00000002
eax=866d8028 ebx=866d0008 ecx=00000000 edx=00000004 esi=866d0000 edi=866d8028
eip=f78e9e12 esp=80555f44 ebp=00000000 iopl=0 nv up ei pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202
inspect+0x8e12:
f78e9e12 ?? ???
Resetting default scope

LAST_CONTROL_TRANSFER: from f78e9e12 to 804e0aac

STACK_TEXT:
80555ed0 f78e9e12 badb0d00 00000004 f78ea247 nt!KiTrap0E+0x238
WARNING: Stack unwind information not available. Following frames may be wrong.
80555f40 860dac01 867719e8 866d8028 f78e7306 inspect+0x8e12
00000000 00000000 00000000 00000000 00000000 0x860dac01

STACK_COMMAND: kb

FOLLOWUP_IP:
inspect+8e12
f78e9e12 ?? ???

SYMBOL_STACK_INDEX: 1

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: inspect

IMAGE_NAME: inspect.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 0

SYMBOL_NAME: inspect+8e12

FAILURE_BUCKET_ID: 0xD1_W_inspect+8e12

BUCKET_ID: 0xD1_W_inspect+8e12

Followup: MachineOwner

[attachment deleted by admin]

John,

I’m sure Egemen will get on your minidump, and have that analyzed.

LM