BSOD on upgrade to 3.0.6-52128, winxp host

[Jeff]

I was running fine with version 3.0.4-50677 but when trying to upgrade to 3.0.6, I get a BSOD. This is on a Windows xpsp3 box and the last line of the BSOD refers to FW.SYS. FW.SYS is a CheckPoint SecuRemote file. I was able to reinstall version 3.04 with no problems.

[misha]

Could you attach a ​minidump of the crash you observed? By default it should be stored under %SystemRoot%\Minidump dir

[Jeff]

Some how I got it to work but now I'm trying to upgrade to VirtualBox-3.0.8-53138 and I'm getting the BSOD again. see attached .dmp file

Jeff

[Jason]

I have this too, and it's really annoying.

Has been happening with a few 3.0.x releases, right up to 3.0.8 today.

VMware happily manages to coexist with the Checkpoint VPN client, why not VirtualBox?

I don't think an acceptable solution is to have to uninstall Checkpoint whenever there's an upgrade to VB.

[Jason]

Update: it would seem that stopping both the Check Point Securemote service, and the watchdog, before installation allows installation of VB without any bluescreening.

[misha]

I'm unable to reproduce this issue here. What CheckPoint Securemote version do you have installed?

[Jeff]

VPN-1 SecRemote NGX R60 HFA2 (Build 044)

Jeff

[Jason]

I'm using VPN-1 SecureClient NGX R60 HFA2 (Build 052)

[pentagonik]

Does this problem still persist for you using VBox 3.1?

[ci-zephyurus]

blue screen of death during vbox upgrade when CheckPoint VPN is installed.

[ci-zephyurus]

Hi,

I am a reporter of bug #4851 which is probably related, but different. (In it, there was a mention of a post related to fw.sys and blue screen of death.)

I experienced a BSOD during upgrade with 3.1.2 just like the reporter here.

What happened is during the ugprade, I experienced a BSOD, and I think this is related to CheckPoint FW1 VPN (secure remote client) installed on my win xp sp3 host. (Host: Windows XP, sp3.)

In my past experience, disabling the checkpoint fw1 vpn network driver(or filter?) in the TCP/IP propety of network setting invoked from control panel solved the problem. But the problem is definitely there.

I suspect that the Vbox network filter doesn't expect OTHER network filters co-existing with it or something during installation, and doesn't take care of the pointer shuffling or interrupts/events thrown at it and doesn't pass them transparently to the other layers of stacked network filters. Wild guess, but since upgrade did work before AFTER I disabled CheckPoint fw1 vpn driver (by ticking off the secure remote vpn filter from the driver list of the tcp/ip property), I think the bug is lurking somewhere there.

I am attaching the BSOD seen during the upgrade. You can see it is stopping in fw.sys, so I am not sure who to blame. *BUT*, on the same PC, vmware player is installed without such a fuss, so I suspect Vbox is to blame here more or less.

[Jeff]

jesoma here again, another version upgrade and another blue screen. Man, this is really annoying! Help please.

jeff

[misha]

Reproduced this issue finally. However I have the same fw.sys crash when installing Cisco VPN client and when there are NO VBox components are installed.
The fail actually occurs when there are multiple failover IM drivers installed on the system.

Since the crash occurs when installing non-VBox networking components as well, I would consider this issue as non-VBox-related.

[Technologov]

A possible solution for your problem is described in Wish #6057

Potential duplicate of this bug found: #6933

-Technologov

[ci-zephyurus]

On the same machine when I reported my earlier comment, VMPlayer installed without triggering the problem from FW.SYS.

I wonder what in VBox trigges the misbehavior of FW.SYS (or other network stack or filter). If it can be identified, it may be a good idea to

• to report the problem to CheckPoint (in the case of FW.SYS), and
• also implement network stack somewhat differently to avoid triggering the bug. (Obviously VMware network stack doesn't trigger the bug.)

But given that there seem to be so many drivers that show similar buggy behavior in #6057, I would go with the second approach of modifying network stack of VBox. (VBox must be using not so often used features not well tested under windows by other network stack drivers.)

But again, I am not sure what causes the problem, and not familiar with the innards of Windows stack. So just a suggestion from arm-chair programmer in this particular case (I DO and have sent patches to Thunderbird, Linux Kernel and other open source projects before as well as free software such as Emacs, but simply don't have time to spend enough time on this particular one. Sorry about this. I hope someone more knowledgeable about windows network stack can help here.)

[aeichner]

Please reopen if still relevant with a recent VirtualBox release.