Endpoint Protection

My employer makes SEP available to their employees in another line of defense against anything bad making its way onto the corporate network. So for quite some time I've been running SEP (current version here is 12.1.6318.6100) on my home computers as unmanaged clients and things were working just fine under Windows 7.  Just recently I updated my wife's computer to Windows 10 and now her EQ7 software refuses to start (click on it, the cursor spins briefly, changes back to an arrow and nothing else happens).  Windows does produce an error (WER) report that in a nutshell says:

FriendlyEventName=Stopped working
ConsentKey=APPCRASH
AppName=EQ7 Quilt Design Software

I wrote the EQ people and described the symptoms and they wrote back to ask if I had SEP on the machine.  I answered yes to which they responded that EQ7 is not compatible with SEP and that I should look into getting different antivirus software.  This statement is somewhat contradicted by the fact that EQ7 was working fine alongside this same version of SEP under Windows 7.  I have tried disabling SEP through the taskbar and that did not help.  I have scanned the SEP logs and have not found any mention, pro or con, of EQ7.

As the EQ7 support at this point seems questionable, I'm looking for suggestions about how I might troubleshoot and fix this from the SEP end before my wife shoots me.

Thanks!

Is SEP detecting the software as malicious? Check the Risk and Security log to see if anything shows up there.

Just a wild guess, but perhaps there is an incompatibilty between EQ7 and SEP's Application Control feature. On an unmanaged client, you can disable Application Control under Change Settings > Client Management > General > Enable Application and Device Control.

When I got home today I uninstalled both EQ7 and SEP 12.1.6318.6100 from my wife’s desktop computer and then reinstalled EQ7 and it did indeed startup and run as it should (with SEP missing). I then downloaded a slightly newer copy of SEP from my company’s server (in this case it was version 12.1.6867.6400 ) and installed it.  After rebooting, EQ7 again failed to start in the same manner.   As a different test, I updated the version of SEP installed on my wife’s Win10 laptop to this slightly newer version and then installed EQ7 on it. There too EQ7 fails to continue to run when launched.  If nothing else, this proves that the problem is repeatable on very different systems.

In answer to Brian, all of the logs are either totally empty or only make mention of SEP retarting or live-update running. EQ7 does not show up in the SEP logs anywhere even though there were multiple EQ7 failures during the times that the logs covered.

In answer to Greg, the Enable Application and Device Control was already disabled. Enabling it did not help. Subsequently disabling it again did not make any difference.

Thank you for your thoughts though!

Oh, and in defense of the EQ7 support people, from my ongoing conversations with them it sounds like they have been up against this one before and got no support from Symantec in helping to solve it so they too are a bit frustrated.

About the quickest way to get to the bottom of this to open a support case with symantec. It sounds though as if you're just running an unmanaged version? You will need an active support contract to get a case otherwise they will just point you back to this forum for assistance.

What happens if you install SEP with only the antivirus component? It could be a specific compoonent causing the problem so you can try narrowingit down by installing one by one.

Yes, in every case these are unmanaged PCs.

No, we are not allowed to use our company's support contract to deal with problems like this at home so it seems I am in the best place available to me to be asking these questions.

I'd start out with only the core files, see what the result is. If that works then add the AV component, see what that looks like. Continue to add the remaining components if it works. At least this way it can be narrowed down to a specific one.

The only choice I have with the installer is whether or not I run it. Once launched, it is ballistic and totally on autopilot until it says that it is time to reboot and go live. After the reboot EQ7 refuses to run.  After SEP is running, it does not matter what part of it I select to disable or if I select all of it to be disabled, EQ7 will still refuse to launch. Once SEP has been installed, the only way I've found to get EQ7 running thereafter is to first uninstall SEP.

Sounds like you were given an unattended install.

After install, you should be able to go into the Control Panel and select SEP and hit 'Change' and then 'Modify'

From here you can then de-select the components. I'd start with the Core Files only.

Thanks Brian, that was a good suggestion.  In the Programs and Features control panel, after right-clicking the SEP item I'm given a context menu where I can select "Change" as an option (default option is to uninstall, which is what happens if you left click on it - no modify choice).

That brings up a Program Maintenance menu where Modify, Repair and Remove are the choices.

From there I was eventually able to narrow the problem down to the Application and Device Control portion of the Proactive Threat Detection component.  With this item uninstalled, EQ7 starts.  When this item is reinstalled, EQ7 refuses to start.

With this component installed, when SEP is opened I don't see any Configure Settings options related to Application and Device Control which might be changed to modify SEP's behavior.   Am I missing anything?    Or is the only "fix" for this* is to leave the Application and Device Control  component uninstalled?

*assuming this discussion doesn't pique the interest of a Symantec developer who wants to know why their product is doing this to a harmless program in a manner that is totally beyond the reach of the "disable all SEP functions" control as well as every other setting available within the SEP interface.

You cannot configure application and device control from the unmanaged client. This component is best used for enterprise machines. I would leave it disabled as this seems to be the workaround.

If you had a support contract you could get a case open but in your situation leaving it uninstalled will work just fine.

Warren and Brian, thanks for working this out. We did reach out to Symantec a while back, but without a valid support contract no one would discuss this issue with us.

I have created an article on our support site that docuements this issue and the workaround suggested.

You may want to link that article here in case anyone else comes across the same issue and can workaround it properly.

Here is the support article I mentioned:

http://support.electricquilt.com/Problems-opening-EQ-while-using-Symantec-Endpoint-Protection.ashx

Feel free to let me know if I missed anything.

A few changes I would make to the first part of the article just for clarity sake, I bolded them for better readability:

If you are using Symantec Endpoint Protection (SEP) and are having issues opening your EQ software, it is likely your Symantec Endpoint Protection software isn't properly configured to run in unmanaged mode. Symantec Endpoint Protection contains a feature called Application and Device Control that allows IT administrators to control how applications and devices can be used on the computer:

https://www.symantec.com/security_response/securityupdates/list.jsp?fid=adc

This feature can not be configured by the end user in unmanaged mode.

Again this issue only affects users of SEP running the software in unmanaged mode. If you are not running in unmanaged mode, please contact your IT Administrator to add permissions to your computer to run EQ Software. If you are running in unmanaged mode, please remove the Application and Device Control feature of SEP from your computer.

I'm sorry to hear that Symantec isn't working with you on this. A shame really since you're both vendors and I always thought vendors worked behind the scenes pretty closely when each other's software doesn't play nice for whatever reason. If you'd like, PM me and I'll see if I can help.

Thanks,

Brian

Thanks to Matt at EQ for the quick diagnosis of the EQ7/SEP conflict and especially to Brian here on the Symantec forums for helping me find an acceptable workaround (note that this is NOT a fix for the root cause of the problem!)

I second Brian's sentiment that Symantec and EQ should really learn to play nicer together, both as programs and companies and I look forward to the day when the root cause of this problem is fully understood and is truly fixed so that it does not cause others similar grief.

While it would be nice to leave this discussion open and "unsolved" as a niggling little reminder to Symantec that their software remains flawed, that would not be fair to Brian who spent his valuable time helping me to work through this. So, at the present time I won't be greedy and will accept the work-around as a solution.

Thanks to everyone again!

Thanks Brian. I made the suggested edits to our support article and sent you a PM.

Thanks, it looks good.

I responded to your PM but we'll keep it going there so as not to clutter up this thread :)

Circling back around on this, it should also be possible to add an application exception as well, instead of needing to remove the ADC component. It would need to be tested first though to make sure it works.

Hi Brian,

I thought I had tried that at one point. I know that at some point, somewhere in the SEP settings, I had browsed to the EQ7 executable and there told SEP to "leave this one alone" but perhaps I did not set it up correctly.  If you could provide a thumbnail of the correct process, I'll try it.

Thanks

You'll want to open your client and go to Change Settings >> Exceptions >> Configure Settings

Click Add >> Application Exception

Should be able to just add the executable name and save the change.

I modified the SEP installation to add back in the ADC component and, after rebooting, went into SEP and added an exception for EQ7.exe.

I tried the exception with both the "Ignore" and "Log Only" settings (and also after a reboot) and in all cases SEP prevented EQ7 from running. Only when the ADC component was again uninstalled could EQ7 run on the machine. 

Because SEP is ignoring settings like this (or the more general "disable everything for a while") tells me that something else, which no one yet understands, is going on with this ADC component and it may be a bit more buggy than the Symantec folks know or are willing to admit.

How unfortunate. At this point, removing the ADC component is the only workaround.

Some background (and a proposal):

Application and Device Control (ADC) is using the sysfer.dll library. It will be injected into the process stacks to monitor, block, allow or log activities. Unfortunately there are some apps which are incompatible with sysfer.dll. See this article on this topic:

Creating Application Control Exclusions in Symantec Endpoint Protection 12.1

For managed clients, it's possible to define an exclusion in the Exceptions policy in SEPM for Application Control. If you do that, sysfer.dll won't be injected into the respective process stack.

Unfortunately, it's not possible to define this exception at the client GUI. Even if you disable ADC (proposal in my first post) you don't get rid of sysfer.dll. You have to disable the ADC component, as Brian wrote.

There is another solution if you have access to a SEPM and you don't want to remove ADC:

• Create a new, empty group
• In this group define the settings and policies for the unmanaged client -- in particular in the Exceptions policy the exclusion for EQ7 (the article above describes how to do this)
• Create an unmanaged client install package (.exe file), tied to the new group
• Run the install package on the target box (or deploy it remotely).

See here:

How To: Create an unmanaged client install package from the SEPM with custom policies

Of course this solution is awkward and definively not elegant. However, you can keep ADC running. It's even possible to create rule sets for ADC (not possible in the client GUI).

With tools such as Process Explorer or Process Hacker, you are able to check if sysfer.dll is in the process stack.

HTH!

The problem is EQ has a DRM check in built-in. ADC invalidates this by trying to inject sysfer and the app fails to start. Whether creating an exception or disabling ADC, it fails.

The other issue is this software is geared towards "personal use" so access to a SEPM is unlikely.

Not sure if you're right because sysfer.dll will not be launched if the particular Application Control exception (defined in the SEPM) is used. So it should have the same effect as removing of the component. This exception has nothing to do with Application Exceptions in the client GUI. 

AFAIK, Application Control exceptions are the only ones you can only create in the SEPM, not at the client GUI.

I'm talking from an unmanaged perspective. The only workaround has been to remove the component on the unmanaged client.

The option to add an "Application" exception exists on the unmanaged client, but, clearly it is not for ADC.

The option to add an "Application" exception exists on the unmanaged client, but, clearly it is not for ADC

You are right, and therefore you have to use the "embedded" Application Control exception from SEPM for a particular application. This works well, I tried it with an unmanaged client with such an embedded Application Control exception. sysfer.dll was not visible in Process Explorer for this app. So I think it's worth a try.

Just to clarify:

Application exception: Exception that can be set in the client GUI, not useable for ADC

Application Control exception: Exception that can only be set in the SEPM (the stuff I'm talking about here).

Correct. And while your workaround will work, the struggle becomes getting IT to create this one off exception for personal use. And should something change in terms of needing  a different exception, it's additional work, albeit not difficult to do. In addition IT is now tasked with assisting in personal use cases. In every environment I've been in, that will get a "Yea, Ok" eye roll. But I suppose it doesn't hurt to try. Unmanaged ADC provides limited value aside from blocking autorun.inf so removing is the lesser of two evils. If only SEP provided better functionality for unmanaged ADC, it would solve a lot but seeing as how ADC isn't geared towards regular users, it's easy to brick a system. But that's just my two cents.

But that's just my two cents.

Generally speaking, now there are already 4 cents ;)

However, the Application Control exception cannot freeze or brick the PC as it's a simple Exception policy rule. Either it will work or not. Only Application Control rules are really, really dangerous.

I'm referring to the dangers of using the Application Control rules incorrectly in regards to bricking a system.

Hi guys,

I was out of town for a couple of days so I'm playing catch-up here.  No I do not have access to SEPM. And I will not be getting a custom build of the unmanaged client from my employer as this is their position on SEP support:  [company name] provides this software as a benefit to employees but does not provide support other than the [provided end user guide]. In a nutshell, this fix is a non-starter for me.

If this ADC component cannot be managed with tools available to the end user of the unmanaged client then it should not be installed with the unmanaged client which is the conclusion I think we reached, but by another path. If all it costs me in doing so is autorun protection, then that's a small price to pay since there are other ways to address that concern.

Thanks!

I would also like to point out that autorun.inf files are only run on CD/DVD ROM drives in Windows. If your computer doesn't have a CD/DVD ROM drive (alot of new laptops don't), then you aren't losing any protection based on my understanding of Brian and Greg's conversation.

It can also affect network drives, in terms of virus propagation.

autorun is dangerous and SEP would help protect against these types of outbreaks but I believe in later versions of Windows it is disabled by default.

I make alot of Windows Installers as part of my work. Windows 7 and up only allow autorun.inf for CD/DVD ROM drives and I am pretty sure the "Always perform this action" checkbox was removed from the autorun dialog in Windows 8.

Some USB manufacturers workaround this by installing the USB as a virtual read only CD/DVD ROM drive, but this is very uncommon and is only something I have ever seen with factory data preloaded USBs.