An EdmType cannot be mapped to CLR classes multiple times

A customer site running 10.1.500.14 experienced this same error message today. The Stop/Restart resolved, but should this still be occurring on that version/patch?

The last code change that I’m aware of that dealt with this specific issue was introduced in 10.1.500.7+/10.1.400.22+.

1 Like

Hi, We are on 10.1.400.36 and suffer from this problem, we contacted Epicor support and was told that we needed to update our Microsoft.Net Framework, which we did last last weekend and have suffered this problem once in the week, just recycling the appservers solves this and get our users working again, we will be going back to support next week.

1 Like

I want to update this post with the resolution to the occurrence of this Error for our client. It may prove useful as one example that may save others the headache of tracking down the root issue.

To recap - Users on 10.1.500.14 saw an isolated occurrence of the following Exception message on all instances on their primary app server

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

A quick search of this forum led me to this thread and my previous reply - Quick resolution was to stop/start the app servers for all instances. Operations returned to normal.

AT end of month, we began experiencing this same error message, but repetitively - approximately every 15 to 30 minutes we had to perform a complete restart of all instances - the client was trying to push out their end of month invoicing, so keeping the system up was paramount.

Combing through event logs we found this occurring every few minutes leading up to the eventual crash

An unhandled exception occurred and the process was terminated.

Application ID: /LM/W3SVC/1/ROOT/EpicorLive10

Process ID: 5828

Exception: System.OutOfMemoryException

Message: Exception of type ‘System.OutOfMemoryException’ was thrown.

StackTrace: at System.Text.StringBuilder.ToString()
at Erp.Internal.PE.PEMessage.TryReadUntilFileAccessible(String fileName) in c:_Releases\ERP\RL10.1.500\Source\Server\Internal\PE\PEMessage\PEMessage.cs:line 236
at Erp.Internal.PE.PEMessage.UpdatePostInfo(String newPostInfo, String postingUID) in c:_Releases\ERP\RL10.1.500\Source\Server\Internal\PE\PEMessage\PEMessage.cs:line 188
at Erp.Internal.PE.LogView.UpdatePostInfo() in C:_Releases\ERP\UD10.1.500.14\Source\Server\Internal\PE\PEData\LogView.cs:line 174
at Erp.Internal.PE.LogView.FinalTag() in C:_Releases\ERP\UD10.1.500.14\Source\Server\Internal\PE\PEData\LogView.cs:line 570
at Erp.Internal.PE.Pre_PostBase._RunProcess(Int64 instance_TaskNum, String groupID, PostingMode mode, Boolean skipPEDataInit) in c:_Releases\ERP\RL10.1.500\Source\Server\Internal\PE\Pre_PostBase\Pre_PostBase.cs:line 149
at Erp.Internal.PE.AR_InvoicePre_Post.Pre_Post(Int64 instance_TaskNum, String groupID, PostingMode mode) in C:_Releases\ERP\UD10.1.500.14\Source\Server\Internal\PE\AR_Invoice\AR_InvoicePre_Post.cs:line 419
at Erp.Services.BO.InvcGrpSvc.postGroup(String CurGroup, String& InvoiceNumstring, String& ErrorMessage, String& LegalNumberMessage) in c:_Releases\ERP\RL10.1.500\Source\Server\Services\BO\InvcGrp\InvcGrp.cs:line 1088
at Erp.Services.BO.InvcGrpSvc.PostInvoices(String groupID, String& invoicesGenerated, String& errorMessage, String& legalNumberMessage) in c:_Releases\ERP\RL10.1.500\Source\Server\Services\BO\InvcGrp\InvcGrp.cs:line 1213
at Erp.Services.BO.InvcGrpSvcFacade.PostInvoices(String groupID, String& invoicesGenerated, String& errorMessage, String& legalNumberMessage) in c:_Releases\ERP\RL10.1.500\Source\Server\Services\BO\InvcGrp\InvcGrpSvcFacade.cs:line 221
at Erp.Internal.SR.InvoiceFromShip._InvoiceFromShip(String ip_PackNum, String& op_ErrMsg, String& op_Message, Boolean& op_StopShip) in C:_Releases\ERP\UD10.1.500.14\Source\Server\Internal\SR\InvoiceFromShip\InvoiceFromShip.cs:line 333
at Erp.Services.BO.CustShipSvc.InvoiceShipment(String company, Int32 packNum) in C:_Releases\ERP\UD10.1.500.14\Source\Server\Services\BO\CustShip\CustShip.cs:line 33066
at Erp.Services.BO.CustShipSvcFacade.InvoiceShipment(String company, Int32 packNum) in C:_Releases\ERP\UD10.1.500.14\Source\Server\Services\BO\CustShip\CustShipSvcFacade.cs:line 1808
at SyncInvokeInvoiceShipment(Object , Object , Object )

Error continued to appear and crash the system into the next day, but always coincided with Invoice processing. By midday stress levels are at their peak across the organization and things were about to get :face_with_symbols_over_mouth: when the root cause was identified…

a couple of weeks previously the client had engaged Epicor technical support to troubleshoot a mass printing. During that session, the technician had enabled the Posting Engine Logging on the Live environment…but failed to turn it off after completing the session.

As days went by, the PELog.txt file became “enormous” and too big to load, and would crash the Application pool each time the posting engine tried to access the file.

For reference the PElog.txt is typically located here: \EpicorData<Company>\PE\Pelog.txt

Once we confirmed the file location and size - > 1GB we deleted the file and processing resumed normally - no recurrence of the error. There was much rejoicing!!!

An Epicor direct consultant help dig up the instructions for disabling this logging - posted below for reference should anyone else stumble across this thread due to a similar error message.

Thanks to the powers that be for providing this forum - I hope this info saves the life of an Epicor Sys admin or two down the road.

4 Likes

Interesting - so did memory pressure force the app pool to recycle?

That looks like two aspects.
The visible one every sees about edmtype blah blah which was the threading bug we worked around in Entity Framework. That occurred when two (or more) client calls hit the server and asked to stand up EF for the first time that app pool lifetime - EF choked when it started standing up the data model and it already was on another thread.
The trigger is that the app pool was recycled - you found out why in that post.

Makes sense now…