Client Update issue (Testing Needed)

Epicor ERP 10
, ,
1

We ran an update to a patch 10.2.500.27 and we are intermittently getting an error where it says that Epicor.exe is in use (when it clearly isn’t)

During the upgrade process (at the end)

We can break it pretty much on command by calling /update on the shortcut and it will do it once every other time or so

I’ve done a lot of testing and I believe it is a timing issue. That is the Epicor.exe from the patch is copied in and immediately it tries to access it but it can’t

We are trying to determine if it’s a bug, a windows update or security software intervening

Any volunteers to break their local client install for science?

On any version on or above 10.2.500.27?

image

I’d love some feedback

All you have to do is add /Update at the end of your shortcut and then double click it (on your workstation)

It should force it to re-download your client

I’m curious if anyone else is seeing this behavior it is pretty consistent for us across the organization which leads me to believe is a windows or a security issue

I haven’t been able to replicate on a non corporate workstation (yet)

Thanks!!

PS: To fix it all you have to do is remove the update flag and since your version hasn’t actually changed it should be fine or you can re install yo it client but obviously don’t break a production workstation if you don’t know how to fix it

#ForScience!

2

From memory, I think we have faced that issue in another version. And I think we have added /skip in the shortcut in order to avoid definetly the error message… Not sure about this one…

3

Skip would work to avoid the error but we really need to be able to deploy upgrades

4

Isn’t there two update methods? One that downloads the individual files and the other that downloads a zip file.

5

Yes this one is the zip method
Downloads the zip fine but it fails after the unzip

6

Could an antivirus program be interfering?

7

Yes I believe that may be our issue ir a bad windows update

8

Just the two cents from the resident network/admin guy. Stop relying on an applications update mechanism and get systems automation in place to handle these things. Out of band updates/upgrades are ALWAYS a better way to go because in the event of a catastrophic failure of the internal automation (Epicors Upgrade process for example) your actual fix methodology is still the same piece of automation that controls the upgrade. For example we dont manually do ANYTHING except add a workstation to the domain. Automation handles everything else. Installation of everything from Chrome, to AV, to Epicor, even down to the barcodes font files to support crystal report generation. #2Cents

9

I printed an SSRS Report to Excel, I left that report open overnight, so today I forgot I still had /Update and it failed… I couldnt even rename the Client folder, so trying to figure out what in the world is still having a lock on it (I closed everything)… turns out Excel.exe left a lock on it… PERHAPS Because it was launched as a sub-process (Open with Excel, SSRS to Excel).

image
image863×593 41.2 KB

Maybe your issue too… Nontheless make sure you close all your files :slight_smile:

10

At last!!! thanks to SysInternals tools and (Mark Russinovich MCM :heart_eyes: frigging genius that guy) I was able to find the culprit.

One of our security systems (via Manage Engine) uses a tool called “VerifyTrustedFiles.exe” which is supposed to monitor executables and do some crap I don’t know.

Anyways thanks to Process Monitor I was able to see that AutoUpdate.exe copies Epicor.exe (from the latest patch we were installing) successfully
Then VerifyTrustedInstaller immediately opens that file and starts snooping around (as it should) but it creates a write lock on the file.

AutoUpdate.exe then tries to (again) open Epicor.exe to launch the program or who knows why and it gets a SharingViolation and explodes.

image
image1044×69 30.1 KB

image
image1351×145 93.6 KB

Fix is to disable this feature or add Epicor.exe to an exception list.

2 Likes
11

There is a more robust KB Article, but in a Nutshell even @aidacra always recommended some exclusion such as:

Epicor Servers - If you have AV on Server
X:\Epicor*
X:\inetpub\wwwroot\EpicorERP*
X:\InsiteShip*
X:\Program Files (x86)\Common Files\Epicor Software Corporation*
X:\Program Files (x86)\Common Files\Epicor Software*
X:\Program Files (x86)\Common Files\Epicor*
X:\Program Files (x86)\Epicor Software*
X:\Program Files (x86)\Insite Software*
X:\Program Files (x86)\Microsoft SQL Server*
X:\Program Files (x86)\Seagull*
X:\Program Files\Microsoft SQL Server*
X:\ProgramData\Epicor Software Corporation*
X:\ProgramData\Epicor*
X:\ProgramData\EpicorSearch*
X:\APM*
X:\Applications\EKM*
X:\BarTender Formats*
X:\BarTenderData*
X:\BarTenderTaskList*
X:\Epicor*
X:\Epicor\ERP10*
X:\Program Files (x86)\Insite Software*
X:\SQLDATA*
X:\Website\EpicorERP*
X:\Website\EpicorERP-EMA*
X:\Website\EpicorERP-Help*
X:\SQLDATA*

Epicor Clients
C:\ProgramData\Epicor*
C:\Program Files\Epicor Software*
C:\Program Files(x86)\Epicor Software*
1 Like