I’ll take a look at Xen as soon as I have time for this. Xen does not seem to be an easy thing to setup and configure. The behavoiur you have reported looks very strange. What WinpkFilter version have you installed on that system? Has the instalaltion went smooth? Network blocking may happen if driver is installed but not loaded (because of signature problems) in x64 Windows. Have you lost the connection immediatly after driver installation? Was you able to reconnect before rebooting? After the reboot? There is a chance that during the installation process the network was already blocked (driver started installing) but Windows still needed some sort of interactive confirmations from you, so the installation has not completed succesfully causing the network getting down.
Why you don’t provide option to bypass packets when the buffer is full?
This is done to prevent packets to bypass filtering. Most of WinpkFilter applications can’t afford passing unfiltered packets. However, this can be done in custom driver build.
Why you don’t provide WinPKFilter to close application capture event handle when it detect application does not response or does not process packets it specific time?
Same reasons as above. Application can be not getting CPU time for some period, but it does not mean that security has to be broken and filtering should be dropped. Filtering is turned off if and driver is reset to default state only if all user mode WinpkFilter clients are terminated.
Is WinPKFilter report it to a log file when such issue happen? How we can find the original reason of such issue?
I don’t see much sense in logging such an event as it does not really provide an information what has happened. Check your code for reading packets from the driver. This is the only way.