This post's goal is to help you identify risk in working toward the worthy goal of patching VSE.
"When we release a patch, we want you to patch the product."
Expect the software to evolve to meet the needs of combating malware at the Endpoint.


NOTE: Our base-install package is a .MSI file; the base-install files change whenever we post the product. We post the product whenever we release a patch; thus, the current posted package will always include the latest patch as part of the base-install. Also, the patch install package is a .MSP file, to be used to update existing installations of matching version to be at the latest patch level, i.e. VSE 8.8's patch4.msp is for updating any VSE 8.8 prior release (exceptions are documented in the patch release notes).


What goes into a PatchExplained

Interim releases between patch releases, intended to solve business impacting issues that cannot wait for the next Patch cycle. The scope of code change is generally small, thus the risk of applying a hotfix is small; however, due to the nature of VSE's code base, it's possible to have a hotfix with a very large scope and thus inherit a very large risk factor for introducing that code to the environment.

POCsProof of concept code. When an issue is reported which we cannot reproduce, we'll create a concept solution for you to test out and verify that the new code does solve the issue. POCs are not intended for long-term production use.
Other fixes

Issues found internally and deemed necessary to address.


Depending on the life-cycle of the product, it may become necessary to add new features to the product in a patch release rather than waiting for the next major product release.

New OS SupportUsually requires code changes on our part to support changes in the Windows architecture (new NT kernel versions) or restrictions being imposed through tightening securities of the Windows platform, as a couple examples. Technically it may be possible to run an older patch level on a newer OS but there will be risk of unexpected crashes or broken functionality until a supported patch release is available from us.


Assess the risk of adopting a Patch
"Just answer 2 questions!"
IMPORTANT: Answer two questions to help assess the risk of adopting a given patch.
  1. "Does this release include MFEHIDK.SYS?"
    This is one of the core driver binaries of VSE. If included, that tells you we have modified our core binaries that integrate with the operating system, the Windows kernel, the brain of your system. That's a critical element of our software meshing with a delicate part of Microsoft Windows and the code has changed. That spells "risk", but how much? Answer the next question.
  1. "Is it a major version, minor version, or build version change compared to what is currently installed?" (Again, you're looking at MFEHIDK.SYS in particular.)


Inherent Risk to assume based on the Delta
None. No changes.It doesn't matter what kind of release this is, the risk is low. Yes, really .

Build version change

E.g.: -->

This means the code has undergone a minor tweak; consider it a low risk release, or in more colloquial terms, "the same, only better".

Minor version change

E.g.:  15.0.x --> 15.1.x

A potentially significant change. Potentially, because the devil is in the details; it may be a low risk release, or it might not.  You could clarify with Support or simply rely on the Patch Rating, since this detail was part of their assessment for deriving that rating.

Major version change

E.g.:  14.x.x --> 15.x.x

Always considered a high risk change to the environment. That's a vast amount of code changes, possibly architectural ones too. You cannot safely assume the product to be "the same, only better", it should be tested thoroughly.


You'll notice that when Patch 5 releases, it'll be using 15.3 version of MFEHIDK.SYS; a minor version change from Patch 2, 3 or 4 but don't be lulled into false security. Lots has changed between 15.1 and 15.3, so in that specific case, the Minor version change should be considered a high risk change to the environment.


Isn't patching VSE just like updating my browser or MS Office?

NO. The software is much more complex than that. As I've tried to convey earlier, there are technologies integrating with the brain of the operating system - perhaps thinking of it like brain surgery is appropriate. You are the doctor, and so should prepare for the task you're about to undertake. Your systems are the patients, and you're about to put something new into their heads . A wise doctor would test the procedure first and monitor the patient afterwards for any ill side-effects. Also, not all patients are the same, so it may be wise to have a patient trial in each unique group of your environment.