After E10.1.400.22 to E10.2.300.2 upgrade, client hangs for 2 minutes after each program (window) is opened

We are testing upgrading to E10.2.300.2 (we had no issues with E10.2.200.13) and are experiencing a very odd issue. I am at the point of running the various conversions (section 3.1.4) on the Epicor server which requires launching the client. The initial launching of the client feels normal. Once the application is open, I can initially click on a menu item, but it appears to go into a hang state and will not respond for nearly 2 minutes. Once the 2 minutes elapse, I can navigate around in the menu with no issue. Once I double click to launch a menu item, the same thing happens and the program launches, but then goes into the same hang state and will take 2 minutes for it to then respond to the first click. After that, it works perfectly normal. If I close the menu program and relaunch, it acts the very same way.

As an example, I launch the client. Once the client is open, I have to wait 2 minutes before anything will wake up and allow me to navigate the menu. I wait the 2 minutes and then click around to get to the part maintenance program. Clicking around is normal. Double click on the part maintenance program, it launches and displays normally, but then locks up for the 2 minutes. After that, I can click the part button, search button works normally, click the search, results show normally, click one part, window loads part data normally. If I close the part maintenance window and relaunch, I again have to wait 2 minutes before I can do anything.

Another thing to note, I do not see the (Not responding) message pop up in the window title bar like it will if there is processing going on. The CPU on the Epicor server is nearly 0% as well as the SQL server. I cannot find any errors in the event logs of either server.

I have also run the performance tool and don’t see anything of major consequence.



So this may or may not be related… but try it anyways. Just had someone at a different company experience a similar issue. Go to Tracing and Enable Trace Logging in that client, then turn tracing off and see if it goes away?

1 Like

Thank you for the quick reply Jose, but no luck.

I found the problem. It’s the .NET version. I had installed .NET 4.7.2 offline update NDP472-KB4054530-x86-x64-ALLOS-ENU.exe as required for 10.2.300. Running windows update and installing the most recent updates for .NET 3.5 and 4.5, the problem has disappeared. The oddest part, I thought 4.7.2 was the most up to date version?

CORRECTION: Nope, the real issue is it’s need for an internet connection. Our sandbox environment doesn’t normally have a connection to the internet. To run the windows update, I opened things up. Once I shut it back off, the hang returned.

Intresting. Try disabling telemetry - E10.2.100.x - Telemetry - Collects Data and Sends to Epicor

Good thought Andris, bit it doesn’t appear to be related. I checked Opt Out for our single company for both configured app servers (prod and test), restarted the server and the delay is there with no internet connection.

this knowledge isn’t in our new KB system, so I’m posting a section of that older KB below. Sounds like this might be your issue?


Excessive client startup times of 1.5 to 2 minutes on the Epicor client on PCs that DO NOT have access to the internet. PCs that do have access to the internet experience normal delays of 5-10 seconds. This timing is after clicking OK to the username/password dialog box.

A network trace while running the ERP client has revealed that mfgsys.exe is repeatedly trying to get to the site using the TCP protocol. The inability to get to this site is leading to the 1.5 to 2 minute login delay.

It is not the Epicor application that is calling This is a known issue with .NET and Microsoft’s Secure Computing Initiative.

Basically, all commercial software is supposed to be Digitally Signed with a Certificate provided by one of a few Certificate Providers. This “certificate” tells the end user that the software being run was provided by a known, and trusted, entity. In order to verify that the Certificate is valid and still trusted, the .Net runtime calls out to the page to get the updated Certificate Revocation List. That is basically a list of Certificates that had been valid and are now no longer valid - either because the license was not renewed or because the Digital Certificate was compromised (stolen/lost/allowed to roam wild). The list itself has an expiration so every so often it is refreshed - causing a slight delay in startup.

On systems that do not have Internet connectivity - for whatever reason - the list is requested each time a .NET application starts up (conditions apply). The .NET runtime really wants this list, so it will wait for about 2 minutes before it times out and allows the system to operate with a “provisional” license (this is where the whole Secure Computing Initiative starts to fall apart). As there have been so many complaints about this behavior, Microsoft added a switch that can be applied to a .NET application that will by-pass the Certificate check (another chink in the Secure Computing armor) and just provide a provisional runtime allowance.

Add the following line to the section. If they do not have a section they will need to add that also. It is possible that the customer will not have a epicor.exe.config file and they can use the attached as a sample for editing an existing version or they can just use this file. It should be placed in the client directory with the epicor.exe executable. (See below of sample config file)

<?xml version="1.0" encoding="utf-8" ?>
      <generatePublisherEvidence enabled="false"/>  </runtime>
                                                <!-- Exception handling switches -->
                                                <!--Valid values are 0=Off; 1=Errors; 2=Warnings; 3=Info; 4=Verbose -->
                                                <add name="LogException" value="0" />
                                                <add name="DialogException" value="0" />
                                                <add name="DeregistrationException" value="0" />
                                                <add name="DashboardException" value="0" />
                                                <!-- Performance monitoring switches (only respond to SwitchLevel.Verbose)-->
                                                <add name="FormLoad" value="0" />
                                                <add name="TransactionLoad" value="0" />
                                                <add name="NotifyAll" value="0" />
                                                <!-- Help Browser tracing (only responds to SwitchLevel.Info)-->
                                                <add name="TraceHelp" value="0" />
                                                <!-- Deployment logging -->
                                                <add name="DeploymentLogging" value="4" />
                                                <!-- Data Tracing (only responds to SwitchLevel.Verbose) -->
                                                <add name="DataTrace" value="0" />
                                                <!-- DataTraceFullDataSets (only responds to SwitchLevel.Verbose) -->
                                                <!-- If Data Tracing is turned on, do we write out full contents of datasets? -->
                                                <add name="DataTraceFullDataSets" value="0" />

The updates 10.2.300.3 has released and fixed the problem. You can have a try.

@Kelvin, I have gone back and reinstalled using the 10.2.300.3 release. Unfortunately, same issue without an internet connection so .3 doesn’t appear any different than .2 did.

@Nathan, I found the code (minus the generatePublisherEvidence node) in the epicor.exe.config file and it was commented out. I uncommented the lines to match what you have shown (some of the values were different and there were a few more listed in the epicor.exe.config file that wasn’t shown in your kb), but still no love.

I then tried using the values and all of the nodes included in epicor.exe.config with no change to the problem.

@tvonderhaar - Not sure if you have resolved but can you try what i did in this post and see if it works for you? Not a permanent fix but looking to maybe give support something meaningful to chase.


@danbedwards - Yep, adding the redirect worked for me as well. Nice workaround.

The issue described in “Interesting 10.2.300 Performance Issue” is being worked on currently. The probable solution is a sysconfig setting that allows declaring whether client has access to internet. Features that depend on internet access can then use the setting to avoid making any process subject to waiting for an internet time out.
The solution should be available in 10.2.300.6.


Thanks @clloyd - really appreciate your quick response and communication on this