An EdmType cannot be mapped to CLR classes multiple times

Having this error, ideas?

Application Error

Exception caught in: Epicor.ServiceModel

Error Detail

Message: An EdmType cannot be mapped to CLR classes multiple times. The EdmType ‘EpicorDB.ABCCode’ is mapped more than once.
Inner Exception Message: An item with the same key has already been added.
Program: Epicor.ServiceModel.dll
Method: ShouldRethrowNonRetryableException

Client Stack Trace

at Epicor.ServiceModel.Channels.ImplBase1.ShouldRethrowNonRetryableException(Exception ex, DataSet[] dataSets) at Ice.Proxy.BO.UserFileImpl.GetByID(String userID) at Ice.Core.Session.setUserDefaults(String userID) at Ice.Core.Session..ctor(String userID, String password, String asUrl, LicenseType licenseType, String pathToConfigurationFile, Boolean fwVerCheck, String companyID, String plantID) at Ice.Core.Session..ctor(String userID, String password, LicenseType licenseType) at IceShell.Apps.LogonDialog.logOn(String userID, String password, Boolean promptUpdatePassword) at IceShell.Apps.LogonDialog.handleLogon() at IceShell.SplashScreenApp.<sbBlurAll_Completed>b__1() at System.Threading.Tasks.Task1.InnerInvoke()
at System.Threading.Tasks.Task.Execute()

Inner Exception

An item with the same key has already been added.

Inner Stack Trace

1 Like


In the short term, STOP (not recycle) the application pool, wait for it to completely remove the w3wp process, and then START. During this time, users should not try to connect to the appserver until it is fully started (~60 seconds after startup / when the private memory of the w3wp stabilizes around 1GB).



@aidacra waht is the w3wp??

w3wp is the Windows process associated with an IIS application pool (aka: what we call the appserver process in Epcor 10).


Now that I know, I am going to make a note of this for future references. Thanks @aidacra

I sent you a message to prevent this condition altogether on your version of 10.1.400 so you won’t have to upgrade to avoid it in the future.

For everyone else, if you are on 10.1.400.x, please upgrade to at least 10.1.400.22 (SCR 193409) to avoid this condition / call into Support for the “permanent” workaround before 10.1.400.22.


Nathan is correct - we worked around a threading issue in standing up Entity Framework. Get the fix!!


image <–I’m absolutely sure that I won’t use this in the future for an unrelated purpose < cough >


Bart - what do you mean by “standing up Entity Framework” ?

We do not have the liberty yet to upgrade from 10.1.400.20 to 10.1.400.22 to resolve a problem with clients getting “epicor is offline” / An EdmType cannot be mapped to CLR classes multiple times. The EdmType ‘EpicorDB.ABCCode’ is mapped more than once.

We have stopped the application pool 7 times already today and this keeps happening and we cannot determine why.

Thanks for any additional information,


Please create a Support ticket mentioning the issue you are running into and we can provide you the “permanent” workaround until you can upgrade to 10.1.400.22+.

1 Like

We have a support ticket opened up already with Alex (I believe), but he left us on the phone about 4 hours ago and did not seem to be aware of any sort of workaround for this… :frowning:

What is your case number? I can provide the workaround via that case.

1 Like

Thanks Nathan!


One of our consultants has access to the SCR’s so we think we might have found the workaround thanks to you supplying us with that number. Sadly Alexis still has not provided it to us. If you could please provide the workaround directly in the case number, CS***********, it would be GREATLY appreciated just so we can directly confirm the workaround we think we found from SCR 193409 is indeed the one you are referring to.

I am not sure what your consultant had in mind, but, if the solution they were proposing was to install a one-off then it isn’t the correct step and will not help.

Only the workaround I posted will help.

1 Like

Are you able to post the workaround direclty in the Epicor case as you mentioned. From the very beginning of my posts I’ve been seeking clarification of the fix that you and everyone have been referring to. The workaround with restarting the application pool had to be done at least 7 times throughout the day today to keep the entire Epicor system online.

Hi Jim,

I posted the workaround in the case around five hours ago

1 Like

Nathan - Thanks a lot for updating our Epicor case! You really saved the day for our users and staff.

Do you have any suggestions for us on how to get the same level of support that you provided if / when we run into major system down / critical issues like this again? The lack of response and lack of sense of urgency and lack of knowledge from our initial support call put us in a real bind throughout the nearly the entire day yesterday. We were scrambling to keep the entire ERP system online digging for solutions / root cause while our support agent let us go to “research” for a solution.

Should we have reached out to an Epicor employee directly? Is there a liaison that we should be reaching out to who might have access to the knowledge-base / experience / resources / expertise who could have maybe provided this solution much faster / from the initial description of the issue?

Either way you have done enough for us already, but I figure I might as well pick your brain since you obviously kick ass at your job.

Thanks again.

Update: After implementing the “workaround steps” you provided in our case, we have experienced a repeat of the very same issue twice already today… :frowning:

Any additional help would be extremely appreciated.