hard lock of system with framework installed

[appdriverguy]

Have a laptop that has wireless network card and a wired network jack. It’s running XP x86. With the driver installed and with VPN logged on (over wireless) attempting to access network over UNC path causes an immediate system freeze. No display update, no mouse movement, nothing. It acts like an embedded int3 is hit, or an fpu state corruption. It has a Linksys Wireless-G Notebook Adapter with SpeedBooster.

I’ve uninstalled the framework and no lockup occurs anymore. I did have WinDbg installed as a post-mortem debugger but that didn’t popup. No crash or anything else logged in event logs.

appdriverguy

[Vadim Smirnov]

Looks like a dead lock on the driver level (conflict with another NDIS-hook driver). What kind of VPN are using? Is it built in Windows VPN or third party one? Do you use any third party firewalls on that system?

[appdriverguy]

Thanks. It has Cisco VPN. Hopefully the issue will go away once we start using a custom driver.

The network stack on the wireless and wired connection has the following:

Client for Microsoft Networks
Odyssey Network Services
Deterministic network Enhancer
File and Printer Sharing for Microsoft Networks
QoS Packet Scheduler
Internet Protocol(TCP/IP)

I suspect the Odyssey client. I believe that’s something that the Linksys installs

appdriverguy

[Vadim Smirnov]

Hmm, we have not heard of incompatibilities with these particular software, but it is still possible. It can be Cisco VPN (though if it is I guess we’d heard about this before but we did not) or Odissey (most probably because I’ve never heard about this software). The only way to get the exact answer is uninstall each of these services and check if problem is gone.

For the cases when incompatibility raises you still have an option to use NDIS IM version of WinpkFilter. It is less convenient in installation but it should not conflict with any similar software by design. NDIS hook is widely used but we can guarantee only the compatibility with WinpkFilter derived solutions, other third-party drivers may break WinpkFilter functionality as it is noted on the product homepage.

[appdriverguy]

Ok some more info… I ran into the exact symptom of deadlock on another machine. This one did not have Odyssey client or Cisco VPN. Rather, it had Microsoft Firewall enabled on the network interfaces. I turned off the firewall and haven’t seen a lock occur so far.

Another thought I had is how well does the framework work with power management. I had let the system sit sniffing packets for awhile and the power stuff kicked in to turn off the monitor. Would the OS be foolish enough to power down the NIC even though it’s hooked and still getting packets?

Thanks.

appdriverguy

[Vadim Smirnov]

Ok some more info… I ran into the exact symptom of deadlock on another machine. This one did not have Odyssey client or Cisco VPN. Rather, it had Microsoft Firewall enabled on the network interfaces. I turned off the firewall and haven’t seen a lock occur so far.

Probably this is some other sort of software you use on both of these systems. It is impossible to say more without deep analysis of drivers installed. Windows Firewall should not make any problem.

Another thought I had is how well does the framework work with power management. I had let the system sit sniffing packets for awhile and the power stuff kicked in to turn off the monitor. Would the OS be foolish enough to power down the NIC even though it’s hooked and still getting packets?

WinpkFilter intercept binding between protocol and NIC driver and not the NIC itself. So if OS will turn off the NIC you won’t see any packets from this NIC until OS power it back on.

[Author]

Posts