Video Screencast Help
Scheduled Maintenance: Symantec Connect is scheduled to be down Saturday, April 19 from 10am to 2pm Pacific Standard Time (GMT: 5pm to 9pm) for server migration and upgrades.
Please accept our apologies in advance for any inconvenience this might cause.

svs on Vista and trendMicro Office Scan 8

Created: 16 Oct 2007 • Updated: 29 Jul 2010 | 65 comments

Hi,



i'm having problems with SVS installed on a Vista Laptop with Trend Micro Officescan 8.0.



First i did a initial install of Vista on a laptop. Then i deployed the Trend Micro Officescan 8.0 client on the laptop. Everything works just fine. No high cpu-load or what so ever. Then i moved on to the next step and installed the SVS client. (as local Vista admin). The system reboots and after that the cpu load is 80-90%. There's a system process initiated by the system using 40 to 60% cpu. I realised i didn't put the virusscanner in the exclusionlist and thought that could resolve the problem. So i put it in there and rebooted the system. Still the same problem and process claiming up to 60% cpu. Then i killed the virusscanner proces and cpu-load instandly dropped down to 2%. Starting the virusscanner service again created again a high cpu load.



Strange thing is, that i immediatly get this behavour after installing the svsclient. There are no layers imported or activated yet.



The processes of the Virusscanner itself do not claim much cpu



Trend Micro Officescan 8.0 is on the latest version (including patch 1.1) and so is the svsagent.



Please help

Comments 65 CommentsJump to latest comment

AngelD's picture

Did you add the Trend process(es) to the ProgramIgnoreList?

Martin Brasse's picture

Yes, i added the ntrtscan.exe and tmlisten.exe to the ignorelist in the registry and rebooted the system. These 2 exe files are the services of the OfficeScan Client. That's what i ment with exclusionlist

Jordan's picture

Odd. I think I've got access to Trend Micro, let me check a few things.



But while I do, did you place the full path to the .exes?

If a forum post solves your problem please flag is as the solution

Jordan's picture

So the version I have of Office Scan won't work on vista (it's old) and I'm trying to get a version to test without having to go through their registration processes (since it's enterprise they end up calling and e-mailing me about why I downloaded and other junk I don't like dealing with).



However I did get a copy of the home version, since they don't require all the contact info, and haven't seen any issues--but that's not to say the office scan doesn't.



I also know that with XP it works fine since before Symantec purchased us Trend Micro is what we used here on all our machines.



Also Kasteleman, a really simple test you can run to check to see if the Process ignore list is working is to create an empty layer, add a text file someplace that's easy to reach (like desktop or C:\), activate the layer and then right-click the file and see if it:

1) Scans the file (if it tells you it can't find it that's good--but all AV act a little different on wheither or not it will scan a virtualized path with the process is being ignored)

2) if it does scan the file check to see if it got pulled to the base by deactivating the empty layer and seeing if that text file disappears or not.

If a forum post solves your problem please flag is as the solution

Martin Brasse's picture

Ok, will check that tomorrow as sone as i'm in the office. The entry in the ignorelist is as the prepopulated ones. So starting with [_B_]PROGRAMFILES[_E_]\ followed with the subdir until it reaches the ntrtscan.exe file. Or do i have to put it into " " because there are spaces in the name (Trend Micro\) or use the shortname i.e. with ~1 in it?



Strange thing is, that it is in the combination of svs, vista and Trend OfficeScan 8. Windows XP SP2 with svs and Trend OfficeScan 8 works just fine. Only 2% cpu with 10 layers active.

Jordan's picture

you shouldn't need ""s or the shortname.

If a forum post solves your problem please flag is as the solution

Martin Brasse's picture

I created an empty layer. Added a dir like data. Put in a textfile and scanned the file. Trend Micro scans the directory and reports that it cannot find any virusses. Afterthat i deactivate the layer and the directory dissapears including the created textfile. So it does not get pulled to the base.



Martin

Martin Brasse's picture

Update:



Removed officescan 8.0. Downloaded Trend Micro Antivirus plus Antispyware. Installed it. Now cpu-load drops to 7~10%.



Martin

svallmen's picture

This proves, that yout OnDemand scanner is not in the ProgramIgnoreList or is not properly trated as beeing there by SVS.



But does this mean anything? I guess the offender was some OnAccess Guard.

Jordan's picture

ya, the best thing to try (And it's a hassle I know) would be to add all the possible EXEs to the process ignore list by just going through the trend micro folder and adding any you see. Then start removing them one by one to see if you hit the problem EXE.

If a forum post solves your problem please flag is as the solution

Martin Brasse's picture

svallmen,



what do you mean by This proves.. The fact that installing another virusscanner solves the problem? Still odd that this does not happen with the same scanner but then installed under windows XP SP2?



Already added some additional entries in the ignorelist, but still the same behaviour. As sone as i kill the NTRtscan.exe process the problem is gone. So it seems to me, that adding additional exe-files won't solve the problem. Shouldn't i see them otherwise in the processlist (used processexplorer of SySInternals)?



Do i have to use [_B_]PROGRAMFILES[_E_] in the Ignorelist or can i also use c:\programfiles\<dir of virusscanner>?



Can it be, that [_B_]PROGRAMFILES[_E_] isn't read correct and that because off that the ignorelist does not properly trated as beeing there by SVS.



Still don't understand the programignorelist. If i don't put the entry of the virusscanner in there, al the files in the layer of the program get pulled to the base. For example: I did not include the virusscanner exe file in the list and activated painshoppro 7. After that i scanned the system with the virusscanner. Next i deactivated the layer of PaintShop. Result: the files are still on the system. That is in the fslrdr dir as well as in the program files jasc dir, where the files of PaintShop reside. If i populate the Ignorelist and restart the system. Activate the layer and start the virusscan followed by deactivating the layer, then the files are only present in the fslrdr dir. Isn't that the correct behaviour??

Jordan's picture

You do not have to use [_B_]PROGRAMFILES[_E_] but it's recommended, but it shouldn't make a difference since that's just a variable that points to C:\Program Files (or where ever you happen to have your program files installed).



Yes that's correct behavior, but not all AV will pull from a layer to the base on a scan--only ones that open up for write access (like Norton) when they scan will cause this behavior. Basically all that this does is hide the virtualized path (the non-FSLRDR path) of an application from whatever process is in that list, this is useful in a lot of ways since both AV and Firewalls don't like seeing two paths and many different issues can happen--such as a high CPU load.



That's why we recommend using the Process Ignore list for all AV and Firewalls, I saw Trend Micro (the home version) using about 10% cpu without the process ignored and normal behavior (around 2-3%) with it ignored. Again, since I haven't been able to get the office scan, I don't know what's going on in that case but what I think Svallmen was saying is there's a second process--an on access guard--that running separate then NTRtscan, but requires that process to run, doing the actual scanning which is why ignoring NTRtscan.exe isn't doing anything for you.

If a forum post solves your problem please flag is as the solution

Martin Brasse's picture

Ok, but then again i have to see that process in processexplorer don't i? And it is the system process owned by the system that's using 50-60% cpu. Inside that process resides smss.exe which is a part of the Microsoft Windows Operating System. It is called the Session Manager Subsystem. As soon as i kill ntrtscan.exe this process cpu load dropps and overall cpu load goes down to +/- 4%. Any ideas???

Jordan's picture

I'm not sure what's causing SMSS.exe to be peged, I'll have to do some checking before I can say one way or the other.

If a forum post solves your problem please flag is as the solution

Jordan's picture

So after talking with a co-worker we think that some how SVS and Trend Micro are getting into a recursive loop causing the CPU spikes, we're not sure why SMSS.exe is involved but since this is only on Vista there are a lot of possible new things to take into account that we aren't fully aware of or understand.



If Trend Micro has an ignore list, some Firewalls have these but I'm not sure about AV, I would add the SVS process to that and see if this solves your problem.



If you have paid support I'd contact them and see if they can help if not I'll see if I can look more into this next week but I can't guarantee anything (I'm not actually support).

If a forum post solves your problem please flag is as the solution

Martin Brasse's picture

THX Jordan for you're effort. I'f contacted Trend Micro's support and opend a case. They already asked for some logging and debugging. I'll keep you informed. Btw, you advise to add the SVS process to a ignorelist. Can you tell me the name of this one?

svallmen's picture

quote:
Originally posted by: Kasteleman

svallmen,



what do you mean by This proves.. The fact that installing another virusscanner solves the problem?




Sorry. I don't know why I did not mention in any way that I was refering to one post further back. So, the fact that you were able to scan a file in it's virtual location proves the scanner is not ignored by SVS. If it were, it could not see the file in it's virtualised location, but could see it only in SVS's redirection area (even if this is hidden for normal processes).



Martin Brasse's picture

Small step forward: Trend Micro advised to install 2 hotfixes for Officescan 8. Result: minor improvement, but i found something else:



I had a lot diskactivity, so i decided to look at the started processes again. Found that Superfetch was started. I killed the process and there you go: cpu drops to 2-10%. So i got optimistic and installed the Altiris Agent for NS from within the NS Web Console. Now the cpu load is around 50%.



;-)

jasonf's picture

I have been having the same problem with Trend Micro SMB 3.6 and some new Vista laptops that I have. Once Altiris SVS is loaded and I load our office 2007 vsa or any other one, the system is almost unusable. If I uninstall Trend Micro I'm fine, I've tried excluding the "Altiris" directories and some hotfixes from Trend Micro, but still nothing has helped.



Have you gotten any further with your problem?

Jordan's picture

Did you make sure to exclude trendmicro from SVS?

If a forum post solves your problem please flag is as the solution

jasonf's picture

As of right now I have only excluded the directories for Altiris and SVS from Trend Micro. That has not helped so far.

jasonf's picture

I've been testing this more today, and if I don't have any layers activated my CPU usage will drop down to 4-8% range, once I activate any layers (Adobe, Office 07, MSN messager etc) my usage jumps up to 50-80% and if you reboot the system it can barley even login then. This is of course if Trend Micro SMB 3.6 is installed on the box. If its not i'm looking at 10-18% usage with several layers activated.

mwareman's picture

I've been doing more looking at OSCE 8.0 on Vista (since, at work, I have a coprorate license).



We don't mix SVS here - because we don't use SVS at work (I use it personally) - but thought I'd offer this.



OfficeScan copies itself to C:\Windows\Temp as a randomly named .exe - and that is the on access scanner process that is then spawned. There is also a watchdog service that respawns randomly named copies if necessary..



This is done so that malware cannot identify the binary if it want's to kill the AV process.



As far as SVS is concerned - this means you would have to add C:\Windows\Temp\*.exe to the 'ProgramIgnoreList'. Is this even possible? Can wildcards be used there?



Michael.

Jordan's picture

No, not that I'm aware of.



I know that adding trend micro to the process ignore list works with XP, I have tested this before, and that removes the constant CPU usage (though the most I ever got was 10% I believe) so I'm wondering if the vista version of Office Scan uses some new vista APIs that SVS doesn't recognize--and thus not work with.

If a forum post solves your problem please flag is as the solution

jasonf's picture

I've still been working with Trend Micro editing Reg - entries etc. Still no new progress on this, I may call Altiris soon and see if I can get some direction from their support.

mwareman's picture

Sorry - Looks like I got mixed up.



The scanner is ntrtscan.exe. It is the watchdog service that creates a randomly named copy of itself - not the on access scanner itself. This way - the watchdog is unlikely to be found by malware - and can restart the scan if necessary..



I'll try putting officescan on my personal machine (with SVS) and see if I can repro and figure anything out.. I'm pretty new to SVS - but have been around Trend for a while.



Michael.

Martin Brasse's picture

Update on my topic:



Still not solved this problem. Even had a WebEx with the supportdesk off Trend Micro. They discoverd that this issue might be related in too many files handled in the system and causes the system slow.

On request i made a full memorydump of the system initiated by using the keyboard (http://support.microsoft.com/kb/244139) and uploaded it to Trend Micro.........



Keep you informed....

mwareman's picture

I havn't contacted Trend.. but (using ProcessExplorer) it is trivial to spot that the 'System' process is taking the CPU. When you examine the running threads - it is multiple instances of 'TmXPFlt.sys' taking all the CPU.



I've had this issue before with Trend - a couple of times. Both instances turned out to be bugs in the Trend filter driver that get's installed. I don't think this is an SVS issue at all.



If you've already spoken with Trend - I'll leave you to work with them. Make sure they give you instructions on turning up the debug logging for the filter driver to help figure out what is going on..



Michael.

jasonf's picture

Kasteleman - Trend Micro wants me to send all my logs to them today off my Vista boxes and our Trend Server.





What I have done so far



1. Added 4 Trend Micro Processes to the "ProgramIgnorList"

2. Added exceptions for fslrdr director and all Altiris Directories in Trend

3. Patched our Server per Trend

4 Edited the registorys on my Vista boxs

5. Now sending logs to them...



robertser's picture

We are experiencing the same problem. We use Trend and any Vista box that we put SVS on immediately has very high CPU usage. I am very curious what response you have received from Trend. Have you told them about SVS or have you kept them in the dark that it was on the PC as well? Can you let us know what the support case is so we can open one and reference it. Maybe if more customers report the issue it will get fixed faster. This is seriously hindering our SVS deployment since most of our support techs run Vista.

Martin Brasse's picture

Update from Trend Micro:



From the dump we found there is dead lock in the system between our scan engine driver and the Virtualization software driver fslx.



The lock is initialed by Virtualization driver fslx.



From the dump we cannot determine why the driver has to lock, we need the analyzing by the Virtualization vendor.

-----------------------------------------



Please kindly ask our customer to take the following action:



-----------------------------------------



Please have customer let the Virtualization vendor check the dump.



So how to get support? Can i contact the support directly en upload the memorydump to a ftp-server?



jasonf's picture

I have told them about SVS from the start...

My support case is 1-120556951 however I'd actually like Kasteleman to post his support case for us so I could reference his as well. I'm a few steps behind him as we are just getting the logs for Trend Micro with mine. From his post below it sounds like we now pointing the finger at SVS and their driver fslx...



Kasteleman have you called Altiris support yet?








quote:
Originally posted by: robertser

We are experiencing the same problem. We use Trend and any Vista box that we put SVS on immediately has very high CPU usage. I am very curious what response you have received from Trend. Have you told them about SVS or have you kept them in the dark that it was on the PC as well? Can you let us know what the support case is so we can open one and reference it. Maybe if more customers report the issue it will get fixed faster. This is seriously hindering our SVS deployment since most of our support techs run Vista.




Jordan's picture

I can file a bug but I have to be able to reproduce it which I should be able to try this week sometime.



Bringing it to support is a good idea if you can.

If a forum post solves your problem please flag is as the solution

Martin Brasse's picture

I can bring it to support, because the company has valid license. However what's the entrypoint? My company is located in The Netherlands. Is there a supportdesk in the Netherlands that i can contact?



I also received a new debugmodule from Trend (new 'TmXPFlt.sys'). Testing it now......

Martin Brasse's picture

Tested the debugmodule. Same result. Uploading a new manually created systemdump. Also referenced jasonf support case to Trend. Keep you posted.

robertser's picture

I have a case open with Altiris support. They are trying to replicate the issue now. One of the things that he suggested was excluding the fslx.sys from the Trend Real Time scanner. I'm still testing this but it appears to speed things back up and not utilize as much CPU. I also added in the Trend Process to the ProcessIgnoreList as referenced at the beginning of this thread.

jasonf's picture

I tried the fslx.sys exclude from the Trend Scanner and that did not help with my test systems. I do have 4 of the Trend Processes in the ProcessIgnoreList as well...



robertser's picture

Altiris support was able to replicate the issue and is working on it. I have not received a fix at this time. Hopefully they can assist in figuring out where the problem lies whether it be with them or Trend.

Martin Brasse's picture

Update from Trend Micro:



We have received an update from our Senior Product Specialist..



From the new dump generated by the new debug module, our Senior Product Specialist confirmed that this issue is not caused by our product.



----------------------------------------------------



Finding:



1. According to the dump, we've got more details of this problem. There were 2 locks. 2 locks weren't caused by Scan Engine.



2. The first lock was that the following threads were waiting thread



a996ad78 to access resource 9e7418d8. Thread a2b7fd78 and 9e658030 were waiting for thread a996ad78 to access resource 9e7418d8. Thread a99506b8, a2b16d78, a2a8d3b8, a99703a0, and 865fe130 were waiting for thread a2b7fd78 and 9e658030 to access resource 9e7418d8. At that time, in thread a996ad78, fslx driver dropped the I/O request and then ntfs were waiting for NotificationEvent a3a6e958. In thread a99506b8, a2b16d78, a2a8d3b8, a99703a0, and 865fe130, NTFS driver were waiting for Semaphore a2b2dad8.



In thread a2b7fd78 and 9e658030, NTFS driver was waiting for SynchronizationEvent 9e67abb8. Therefore, the first lock wasn't caused by Scan Engine.



3. The second lock was as the following scenario. The thread 8643eb40 was waiting for Scan Engine scanning thread a2adf7b0 to complete the Scan Job.



In 5 Scan Engine scanning thread a2adf7b0, a2b3d498, a2ae44c8, a9bcdcc8, and a2ae4c60, fslx driver was waiting for Semaphore 9e6212e8. Therefore, the second lock wasn't caused by Scan Engine, either.



4. The locks need fslx driver vendor to check.



5. The problem wasn't caused by Scan Engine. We don't know what fslx driver and ntfs driver is waiting for. The problem needs fslx to solve.



Action:



Please have our customer know the problem wasn't caused by Scan Engine and the problem needs fslx driver vendor to fix. For more details, please reference the dump analysis - analysis_124580_2.zip



Unfortunately i'm not able to open a case with Altiris at this moment. Some problems with the supportcontract...... grrrrr.....



If someone needs the analysis_124580_2.zip file, please let me know...

jasonf's picture

robertser has a case opened up with Altiris already and hopefully they are finding the same results. If not maybe he can forward what you found to them as well. I can call this in if need be, but figure they are already working on the issues, we had them on the phone yesterday with a seperate issue



The call would be free being it's possible the bug is with SVS and Altiris is good about not charging or giving you a credit for future calls when the problem is on their end.



If you could send me the ZIP file that would be great, I will private message you my email address. I want to send it to the Trend Micro Escalation engineer working on my case.



Thanks.



AngelD's picture

From our Altiris forum contact:

Altiris now part of Symantec is working on the issue.



/Kim

robertser's picture

Altiris support informed me today that their development is trying to contact Trends development staff to help them determine where the conflict is occurring. If anyone has a contact inside Trend that might be able to help push things along from their side it would be helpful. I'm sure Trend doesn't see it as a high priority since they do not think it is their problem. But most likely it is going to take co-operation from both companies to fix it.

AngelD's picture

robertser,



Thanks for providing the feedback!

I'm sure Trend and Symantec/Altiris will find a working cooperation to help each other.

Jordan's picture

Support is still working on this and they've created a KB article about it which if you subscribe to you'll be e-mailed as soon as there's a solution/fix.



https://kb.altiris.com/article.asp?article=40084&p=1

If a forum post solves your problem please flag is as the solution

Martin Brasse's picture

Any new updates? Subscribed to get a e-mail as soon as there's a solution. But nothing yet. If it's going to take much longer, the company is considering leaving svs as it is......

jasonf's picture

We are in the same boat, it would be nice to get some sort of update on this.

Jordan's picture

Sorry I don't have any real updates on any type of timeframe, though I can say even if a fix was found and made today it would take at least a month before any Hotfix would be released because of the testing requirements we have before we make anything live. But I also don't know if this will be it's own Hotfix or if it'll be included in the next version of SVS--assuming we can find and fix the problem that is.



I do know that support found that unpatched versions of Vista don't have this problem so there's a certain patch from MS (or group of patchs) that when applied cause this. I don't know what patch does this, and neither does support, however, as soon as support knows I'm sure they'll update the KB article.

If a forum post solves your problem please flag is as the solution

jasonf's picture

great thanks for the update! That would be an option to skip a certain patch as a tempory work around.

Martin Brasse's picture

Like Spriggan set, a unpatched version of Vista doesn't have this problem. So i did a new test. Installed vista on the laptop with the OEM instead of using the Toschiba restore dvd. Used the license (on the back of the laptop) and actived it with the certificat. Then i installed Office 2003 SP2, Altiris NS client and SVS version 2088. I also configured the svsignorelist. Everything just worked fine. Then installed Officescan 8. And there you go. Initial high cpu load. After some time it drops to 4%. So i thought yes!! But unfortunately it's a NO. CPU stays low, but the system isn't that responsive anymore. It feels like one core of the dual core machine is switched off. Excel needs 2 times longer to start and if i open control panel at first it seems like it doesn't response at all. Then after some time it pops up. So yes, cpu load is less but the performance is still very low, even thow i haven't any svs packages imported and activated.

robertser's picture

I just got word back from support that development is still unable to find a fix for this problem. They said the issue appears to be an incompatibility with SVS and the way Vista handles drivers. There is no ETA and it will probably be months before a fix is even found. It sounds like anyone having this problem needs to make it known so that the proper attention can be given to it.

mwareman's picture

Do we know if there is any progress on this issue? Looks like it's been forgotten about.. maybe Symantec dosnt care to get SVS working with a competitors AV solution.. ;-/

jasonf's picture

quote:
Originally posted by: mwareman

Do we know if there is any progress on this issue? Looks like it's been forgotten about.. maybe Symantec dosnt care to get SVS working with a competitors AV solution.. ;-/




What is funny is they use to use Trend Micro when I was there in Utah right before Symantic purchased them. When we used Norton in the past we had a lot of problems, so Trend Micro is now our standard and unfortunatly SVS is now in the process of being removed on all our PCs company wide. Becuase of this and other problems.

Jordan's picture

what are the other issues?



As for the trend peg, SVS SP2 is out and while I don't know if this fixes the trend issue it does fix some issues SVS has been having with Vista which may have been the cause.

If a forum post solves your problem please flag is as the solution

robertser's picture

If you are having this problem please subscribe to the KB article about it. Altiris tracks how widespread a problem is based on how many people have subscribed to the KB article. Right now only 2 people have subscribed to the article so it does not have a very high internal priority. If they know that there are a lot of customers experiencing the same problem then they will be much quicker to get it fixed.



Got to this KB and click on subscribe.

https://kb.altiris.com/article.asp?article=40084&p=1

robertser's picture

I think I finally have a possible fix for this problem.



In your registry make the following changes:

"HKLM\SYSTEM\CurrentControlSet\Services\TmFilter\Parameters" - Add a DWORD value "DisableCtProcCheck" - Set the value to 1



If anyone else is using SVS and Trend please test this out and see if it makes a difference. Still waiting on final analysis to see why this is needed and what else it will do. Would be nice to know if this works for anyone else other than me.

AngelD's picture

Thanks robertser for the feedback!

Could you also please describe or refer to a location what this setting does.



/Kim

robertser's picture

Do not have that information yet. This is strictly for testing at this point. Please assist with testing to confirm the results and if you experience any other problems. Once the dev teams are able to confirm that this is a possible fix then I will be able to get a detailed explanation and have it go through the complete QA process.

AngelD's picture

I don't have access to Trend so I guess Jordan or someone else from Symantec will have to confirm the provided solution/workaround.

Jordan's picture

I've let support know about this

If a forum post solves your problem please flag is as the solution

jasonf's picture

I will try to get this tested on Monday and will post my results.



Thanks,

Jason



mwareman's picture

I just tried this on two separate Vista machines - both with the latest OSCE 8.0 and the proposed registry key.



The key was added and the machine rebooted. Then SVS was installed.



In both cases, 'System' is still consuming *significant* resources (where it did not before SVS was installed). Process Explorer is reporting that the biggest culprit is the Trend Filter driver.



So - this did not work for me.



Anyone else?



Michael.

Jordan's picture

Our tests have shown the amount of CPU being consumed has been reduced but only by about 10%.

If a forum post solves your problem please flag is as the solution

Austin Docherty's picture

Robertser's Fix has worked for me.



I added a DWORD called "DisableCtProcCheck" and gave it a value of 1 to the Registry Key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tmxpflt\Parameters

and the computer has been operating for 48 hours without any excessive CPU caused by SYSTEM or tmxpflt.sys



NOTE: I'm running Vista Ultimate and don't specifically have SVS installed, I only had the issue with excessive CPU usage being caused by TMPXPFLT.SYS under process SYSTEM.