HitmanPro.Alert Blocks .NET 3.5 Install

On a Windows Server 2012 R2 Essentials machine, I wanted to install .NET 3.5, but it kept failing with “Access Denied” whether I did it from the Server Manager or using a dism command.

With the server install source on the I: drive, this is the command I was running (all on one line):

dism /online /enable-feature /featurename:NetFX3 /all
/Source:i:\sources\sxs /LimitAccess

and this is what I was getting:

Deployment Image Servicing and Management tool
Version: 6.3.9600.17031
Image Version: 6.3.9600.17031

Error: 5
Access is denied.
The DISM log file can be found at C:\Windows\Logs\DISM\dism.log

Cause and Solution

It took 10 weeks and 48 posts in a Microsoft partner forum to track down the cause:  HitmanPro.Alert installed a file filter driver that was blocking the .NET 3.5 installation. Note that stopping the HitmanPro.Alert service was not enough. I had to uninstall the program. After a reboot, I was immediately able to install .NET 3.5.

Related notes:

  • This occurred with HitmanPro.Alert version 2.6.5.77.
  • Stopping the HitmanPro.Alert service is not enough. Apparently the service is not the issue; the file system filter hmpalert is what blocks the installation.
  • Changing file permissions on the installation source or on various Windows folders does not help.
  • Process Monitor logging can be misleading:  it may show Access Denied on certain files that it can later open without issue.
  • Fixing the deployment image doesn’t help, but it’s good thing to do after you mess around with permissions etc.:
    dism /online /cleanup-image /restorehealth
  • This also affects other Windows Features. I tested installing Remote Assistance and that also failed.
  • If file system permissions are not causing Access Denied errors, a file system filter driver might be the culprit.
  • Safe Mode is not available on a domain controller. I don’t know if I could have completed the installation (or any installation) from Directory Services Restore Mode (DSRM); I didn’t try it.

Verbose CBS Logging

You can enable verbose CBS logging as follows:

a. On the Start screen, right click This PC and click Properties. Before Server 2012, on the Start menu, right-click Computer and click Properties.

b. In the left column, under Control Panel Home, click Advanced system settings.

c. On the Advanced tab, click Environment Variables.

d. Under System variables, click the New button.

e. A New System Variable will open. Set it as follows:
Variable name: WINDOWS_TRACING_FACILITY_POQ_FLAGS
Variable value: 10000

f. Click OK.

g. Reboot the machine.

Note Verbose CBS logging is for troubleshooting purpose. You should delete the variable after troubleshooting finishes or it may cause performance issues.

Results and Analysis

I ran the .NET 3.5 install from the command line and saw it fail with verbose CBS logging enabled. The log (C:\Windows\System32\Logs\cbs.log) showed this message:

2015-02-22 19:51:48, Error CSI 00000ea9@2015/2/23:03:51:48.988 (F) base\wcp\sil\merged\ntu\ntsystem.cpp(754): Error STATUS_ACCESS_DENIED originated in function WorkAroundBackupIntentForFilesystem expression: TmpStatus [gle=0x80004005]

I’m not sure why, but that message clued a senior Microsoft engineer to look for file system filters. Maybe it was just the fact that changing file permissions hadn’t helped, so what else could cause Access Denied issues on a file? They had me submit an “SDP log,” basically the results of an information capture wizard. In that log, they noticed that the hmpalert filter driver was inserted on every volume:

[02/22/2015 20:08:12] Fltmc.exe Filters
----------------------------------------------------
Filter Name                     Num Instances    Altitude    Frame
------------------------------  -------------  ------------  -----
DfsDriver                               1       405000         0
PROCMON23                               0       385200         0
hmpalert                              337       345800         0
DfsrRo                                  0       261100         0
luafv                                   1       135000         0
npsvctrig                               1        46000         0

------------------------------------------------------------------------------------
[02/22/2015 20:08:12] Fltmc.exe Instances
------------------------------------------------------
Filter                Volume Name                              Altitude        Instance Name       Frame   SprtFtrs  VlStatus
--------------------  -------------------------------------  ------------  ----------------------  -----   --------  --------
DfsDriver             C:                                        405000     DfsServerFilter           0     00000000 
hmpalert                                                        345800     CryptoGuard               0     00000000 
hmpalert              \Device\HarddiskVolume2                   345800     CryptoGuard               0     00000000 
hmpalert              C:                                        345800     CryptoGuard               0     00000000 
hmpalert              D:                                        345800     CryptoGuard               0     00000000 
hmpalert              F:                                        345800     CryptoGuard               0     00000000 
hmpalert              G:                                        345800     CryptoGuard               0     00000000 
hmpalert              H:                                        345800     CryptoGuard               0     00000000  

A little searching revealed that the above output comes from the fltmc.exe development and testing tool. You can run these commands from an administrative command prompt to check filters and their instances. Save output to a text file on your desktop for easier reading:

fltmc.exe filters > %userprofile%\desktop\Filters.txt

fltmc.exe instances >> %userprofile%\desktop\Filters.txt

Remember to deactivate verbose CBS logging (remove the WINDOWS_TRACING_FACILITY_POQ_FLAGS system environment variable and reboot) after capturing the CBS log.

Disable vs. Uninstall

As mentioned above, stopping the HitmanPro.Alert service does not remove the file system filter driver, so I temporarily uninstalled the program.

I see now that is is possible to disable the CryptoGuard feature from the HitmanPro.Alert user interface:

HitmanPro.Alert 1  HitmanPro.Alert 2

I confirmed (using fltmc.exe, described above) that disabling the CryptoGuard feature does in fact remove the hmpalert file system filter driver. So probably disabling that feature would have been enough to allow .NET 3.5 to install.

I still value HitmanPro.Alert for its crypto prevention capabilities. Now I know that I may need to temporarily disable its CryptoGuard feature in order to install Server 2012 R2 features.

Update October 3, 2015:  Windows 10 Issues

I found today that HitmanPro.Alert version 2 also blocked the install of .NET 3.5 on Windows 10 Pro x64.

And I discovered earlier that HitmanPro.Alert 2 caused an upgrade to Windows 10 to crash. After uninstalling Hitman, I was able to upgrade to Windows 10 Pro x86. But when I tried to re-install Hitman, it crashed the OS. I don’t know why it runs on one Windows 10 machine but crashes another.

1 thought on “HitmanPro.Alert Blocks .NET 3.5 Install

  1. Pingback: HitmanPro.Alert Slows Software Protection Service | MCB Systems

Leave a Reply

Your email address will not be published. Required fields are marked *

Notify me of followup comments via e-mail. You can also subscribe without commenting.