I am having an issue that I hope you guys can assist me with.
I first became aware of an issue with the shstat.exe process when I upgraded to VSE 8.8 Patch 5.
When a user logged on to a normal Citrix session through an session the shstat.exe process would bind to the username/ID and when the user logged off the process would still be bound to the user so the user never logs off their Citrix session completely.
It only binds to the first user.This was not the case with Patch 4.
Is the shstat.exe process meant to bind with a user or local system?
I have now found out that this is happening on all our servers not just Citrix through a RDP session
Has anyone come across this issue and has anyone managed to resolve it?
I have a ticket open with McAfee support for the past 4 months and they cannot fix it. The best they came back with was upgrade to Patch 6 which I did and it made no difference.
This issue is caused by the self-defensive behaviour of the VirusScan processes (shstat.exe here).
In this meaning, VirusScan processes have some additional protection compared to other windows processes.
At the end of the TS session, windows tries to log off the user. And the shstat.exe running in the user space cannot be terminated (self-protection).
That's why this session (previous) remains in a hanging/zombie state.
Next time the user tries to log in, TS/Citrix tries to put her/him into the session previously used.
As that session is in an invalid state, the login fails.
To get around this, we have to go down right to the reason: shstat.exe _must_be_closed at the logoff. So that we don't have problems at the next (current) login.
Having the same issue here, I did some research on our ePO to find the exact reason of the problem.
I suspected this is VirusScan>>Access Protection related, so I checked the AP logs.
I have found a whole lot of entries with some lsm.exe not being able to stop shtat.exe
Doing my homework I found out lsm.exe is called Windows Local Session Manager. The name meets the profile described above ...
How to get around this issue (not yet fully tested, but partial results are promising):
1. Set the required/missing exclusion on the ePO server:
Login to your ePO server >> Menu >> Policy >> Policy Catalog >> Product: VirusScan Enterprise 8.8 >> Category:Access Protection >> The policy assigned to your TS/Citrix server(s) >> Settings forerver >> Access Protection >> Common Standard Protection >> Prevent termination of McAfee processes >> Edit >> Add to Processes to exclude : C:\WINDOWS\SYSTEM32\LSM.EXE >> OK, Save
2. Sync the exclusion down to your client(s) (TS/Citrix server(s)):
Go to Menu >> System tree >> Select your TS/Citrix server(s) >> Send Agent wake-up calls to your TS/Citrix server(s)
3. Check if the exclusion appears on your TS/Citrix server(s):
Use the VirusScan Console on your TS/Citrix server(s). Find the same exclusion list locally in Access Protection's options. Check if C:\WINDOWS\SYSTEM32\LSM.EXE is on the list.
4. Try to reproduce the original issue. Test if you still have it or not. You really shouldn't.
(As the original issue was present at the first logged-in user only, this step may involve logging out all your TS/Citrix users. Or waiting for them to log out. Or just to wait until the next monthly patch-restart.)
I tried you method you stated about the LMX.exe.
This doesn't work either, We are having the same issue as well. The problem is that if you dont have enough citrix Licensee and tombstone session are being help by the shstat.exe. You will run of of license for the day. We have 1000 License, and I have to disable the Access protection, then kill the process in task manager for each user.
C:\PROGRAM FILES (X86)\MCAFEE\VIRUSSCAN ENTERPRISE\SHSTAT.EXE
C:\PROGRAM FILES\MCAFEE\VIRUSSCAN ENTERPRISE\SHSTAT.EXE
Yes I see them on the exclustion policy on the servers, But the session will not release.
Please Help us.
I may have forgotten something:
Most important preparational step is to know what exactly is preventing shstat.exe from exiting.
This you can achieve by
1. looking on the Access Protection log on the TS/Citirx server OR
2. creating a query in your ePO about threat events for your TS/Citrix server (narroved down to McAfee process termination).
I have found lsm.exe AND some others, too.
I did not consider all of them important, I may have been mistaken.
Here the Excel pivot I have created for our systems:
You see lsm.exe has by far the highest numbers, but it's not exclusive.
I have added a few others (including wsrm.exe and imaadvancedsrv.exe) to the exclusion list detailed in my first post above.
Avoid adding malware to your exclusion list, add only the ones you are 100% sure about.
Here is what the access protection logs state on 1 server.
|1/18/2016||3:12:04 PM||Blocked by Access Protection rule||NT AUTHORITY\SYSTEM||C:\WINDOWS\SYSTEM32\SVCHOST.EXE||C:\PROGRAM FILES (X86)\MCAFEE\VIRUSSCAN ENTERPRISE\SHSTAT.EXE||Common Standard Protectionrevent termination of McAfee processes||Action blocked : Terminate|
I do have a temporary work around, to assist the users in advance, while this problem is being properly resolved.
Its been working well for the last week.
First choice - Log on to your terminal server with administrative account. Run c:\program files (x86)\McAfee\VirusScan Enterprise\restartvse.exe - You will then see shstat.exe process being held by your own administrative account and not your user. Hopefully you don't use your admin account for day to day work otherwise find another administrative account to use.
Second choice - I have created a very simple .CMD file to remotely run that executable on each server. My .CMD file really does contain many copies of the same command line, but pointing to each server as required. The command line is below, just replace the text servername....
WMIC /node:servername process call create "c:\program files (x86)\McAfee\VirusScan Enterprise\restartvse.exe"
So I run this CMD file from one location in the morning to save users having to call, and again as needed in the day. My CMD file has 30 entries of the same command pointing to 30 servers.
My thinking at the moment is that these executable's can be perhaps started as a service? I'll investigate that today, but I do look forward to official and correct repair from McAfee.
Regards to all
MacAfee support could not fix this issue even with Patch 7
In the Access Protection policy, there’s a category for “Common Standard
Protection” rules, where you’ll find the specific rule “Prevent termination of
That is the rule to modify.
In the “Processes to exclude” text field, add the path and process name
If Windows is installed to other drivers, you could add their references
In the example violation you shared below though, the full path is: C:\WINDOWS\SYSTEM32\SVCHOST.EXE
Thanks for your replys