[Vpn-help] Windows 7 x64 BSOD (again)

[Will Weisser]

Hello,

I'd like to start by thanking you for your awesome VPN client.  I
experienced two BSODs today while not connected to the VPN, but loading them
in windbg shows they are occurring in vfilter.sys (see output pasted below).
 From browsing through the list archives it seems this has been reported
before, so I guess the purpose of this e-mail is just to confirm that this
is happening on Windows 7 Professional 64bit in 2.1.5rc4,  and to see if
there is an expected ETA for when a fix will be available.  I've had the
client installed for a number of weeks so it's odd that it happened twice
today for the first time, but it would be really inconvenient for this to
start happening often, and uninstalling the VPN is not an option at the
moment!

Windows 7 Kernel Version 7600 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0xfffff800`02802000 PsLoadedModuleList = 0xfffff800`02a3fe50
Debug session time: Fri Nov 27 10:41:48.596 2009 (GMT-5)
System Uptime: 4 days 0:33:51.626
Loading Kernel Symbols
...............................................................
................................................................
........................
Loading User Symbols
Loading unloaded module list
........................
*******************************************************************************
*
  *
*                        Bugcheck Analysis
 *
*
  *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {0, 2, 0, fffff800028780b6}

Unable to load image \SystemRoot\system32\DRIVERS\vfilter.sys, Win32 error
0n2
*** WARNING: Unable to verify timestamp for vfilter.sys
*** ERROR: Module load completed but symbols could not be loaded for
vfilter.sys
Probably caused by : vfilter.sys ( vfilter+290f )

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

2: kd> !analyze -v
*******************************************************************************
*
  *
*                        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: 0000000000000000, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on
chips which support this level of status)
Arg4: fffff800028780b6, address which referenced memory

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


READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80002aaa0e0
 0000000000000000

CURRENT_IRQL:  2

FAULTING_IP:
nt!KeSetEvent+226
fffff800`028780b6 488b09          mov     rcx,qword ptr [rcx]

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0xA

PROCESS_NAME:  svchost.exe

TRAP_FRAME:  fffff88007da5fb0 -- (.trap 0xfffff88007da5fb0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffffa800be838a8 rbx=0000000000000000 rcx=0000000000000000
rdx=0000000000000001 rsi=0000000000000000 rdi=0000000000000000
rip=fffff800028780b6 rsp=fffff88007da6140 rbp=0000000000000002
 r8=0000000000000000  r9=0000000000000000 r10=0000000000000000
r11=0000000000000002 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz ac pe cy
nt!KeSetEvent+0x226:
fffff800`028780b6 488b09          mov     rcx,qword ptr [rcx]
ds:0002:00000000`00000000=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff80002873469 to fffff80002873f00

STACK_TEXT:
fffff880`07da5e68 fffff800`02873469 : 00000000`0000000a 00000000`00000000
00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`07da5e70 fffff800`028720e0 : 00000000`00000002 fffffa80`0be838a0
00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff880`07da5fb0 fffff800`028780b6 : fffff880`07da61b0 fffff880`02daaa74
00000000`00000050 fffff880`07da6230 : nt!KiPageFault+0x260
fffff880`07da6140 fffff880`02daa90f : fffffa80`00000000 00000000`00000000
00000000`00000000 fffffa80`0be83890 : nt!KeSetEvent+0x226
fffff880`07da61b0 fffffa80`00000000 : 00000000`00000000 00000000`00000000
fffffa80`0be83890 00000000`00000000 : vfilter+0x290f
fffff880`07da61b8 00000000`00000000 : 00000000`00000000 fffffa80`0be83890
00000000`00000000 fffff880`02daa3fd : 0xfffffa80`00000000


STACK_COMMAND:  kb

FOLLOWUP_IP:
vfilter+290f
fffff880`02daa90f ??              ???

SYMBOL_STACK_INDEX:  4

SYMBOL_NAME:  vfilter+290f

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: vfilter

IMAGE_NAME:  vfilter.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  49703e23

FAILURE_BUCKET_ID:  X64_0xA_vfilter+290f

BUCKET_ID:  X64_0xA_vfilter+290f

Followup: MachineOwner
---------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.shrew.net/pipermail/vpn-help/attachments/20091127/a23714a2/attachment-0001.html>