.NET Runtime error on Appserver testing Kinetic 2022.1.8 -Unhandled Exception-record not found

I have had a seperate environment - an Premise - created to test out Kinetic 2022.1.8. I am getting .net runtime errors on the APPserver event viewer for everything I do. I am starting here so I can get all of the questions answered before I try out support.
Error when
Starting task agent from EAC
Logging into Epicor client.
Opening any app within Epicor.
We have been testing Epicor for some time, and everything is working as expected (maybe a bit slower).
My people who created the environment and another consultant helping me are unable to find the problem.
Is there anything that sticks out here? From the appserver event viewer, every error is the same except for the SpanID.

Category: Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware
EventId: 1
SpanId: ed28909b71cf2dbe
TraceId: 3a0fd8bec0066812029474f99636a8ea
ParentId: 0000000000000000
RequestId: 80000c45-0003-f800-b63f-84710c7967bb
RequestPath: /Kinetic2022_1/api/rpc/Ice.BO.GenXData/GetByID

An unhandled exception has occurred while executing the request.

Ice.Common.RecordNotFoundException: Record not found.
   at Ice.TablesetBound`3.InnerGetByID(IceDataContext dataContext, Int32 pageSize, Int32 absolutePage, Boolean& morePages, TFullTableset tableset, IEnumerable`1 queryParameters) in C:\_releases\ICE\ICE4.2.100.8\Source\Server\Framework\Epicor.Ice\Services\TablesetBound.cs:line 704
   at Ice.Services.BO.GenXDataSvc.GetByID(String company, String productID, String typeCode, String cgCCode, String key1, String key2, String key3) in C:\_releases\ICE\ICE4.2.100.8\Source\Server\Services\BO\GenXData\GenxData.Designer.cs:line 489
   at Ice.Services.BO.GenXDataSvcFacade.GetByID(String company, String productID, String typeCode, String cgCCode, String key1, String key2, String key3) in C:\_releases\ICE\ICE4.2.100.8\Source\Server\Services\BO\GenXData\GenXDataSvcFacade.cs:line 563
   at Ice.Controllers.BO.GenXDataController.GetByID(GetByID_InputModel model) in C:\_releases\ICE\ICE4.2.100.8\Source\Server\Services\BO\GenXData\Generated\GenXDataController.cs:line 220
   at lambda_method807(Closure , Object , Object[] )
   at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.SyncObjectResultExecutor.Execute(IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeActionMethodAsync()
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeNextActionFilterAsync()
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync()
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|20_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Logged|17_1(ResourceInvoker invoker)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Logged|17_1(ResourceInvoker invoker)
   at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
   at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
   at Ice.Hosting.AspNetCore.Middleware.DynamicAssemblyPartMiddleware.Invoke(HttpContext context, CurrentCallInformationService currentCallInformation, ControllerLoader controllerLoader) in C:\_releases\ICE\ICE4.2.100.8\Source\Server\Hosting\AspNetCore\Ice.Hosting.AspNetCore\Middleware\DynamicAssemblyPartMiddleware.cs:line 32
   at Ice.Hosting.AspNetCore.Middleware.AuthorizationMiddleware.ProcessAuthenticatedUser(HttpContext context, IPrincipal user) in C:\_releases\ICE\ICE4.2.100.8\Source\Server\Hosting\AspNetCore\Ice.Hosting.AspNetCore\Middleware\AuthorizationMiddleware.cs:line 53
   at Ice.Hosting.AspNetCore.Middleware.AuthorizationMiddleware.Invoke(HttpContext context, CurrentCallInformationService currentCallInformation) in C:\_releases\ICE\ICE4.2.100.8\Source\Server\Hosting\AspNetCore\Ice.Hosting.AspNetCore\Middleware\AuthorizationMiddleware.cs:line 44
   at Ice.Hosting.AspNetCore.ETags.ETagMiddleware.Invoke(HttpContext httpContext) in C:\_releases\ICE\ICE4.2.100.8\Source\Server\Hosting\AspNetCore\Ice.Hosting.AspNetCore\ETags\ETagMiddleware.cs:line 89
   at Ice.Hosting.AspNetCore.ETags.ETagMiddleware.Invoke(HttpContext httpContext) in C:\_releases\ICE\ICE4.2.100.8\Source\Server\Hosting\AspNetCore\Ice.Hosting.AspNetCore\ETags\ETagMiddleware.cs:line 107
   at Ice.Hosting.AspNetCore.Middleware.DecompressRequestMiddleware.Invoke(HttpContext context) in C:\_releases\ICE\ICE4.2.100.8\Source\Server\Hosting\AspNetCore\Ice.Hosting.AspNetCore\Middleware\DecompressRequestMiddleware.cs:line 41
   at Epicor.RESTApi.Middleware.ApiKeyEnforcerMiddleware.Invoke(HttpContext context) in C:\_releases\ICE\ICE4.2.100.8\Source\Server\Hosting\AspNetCore\Ice.Hosting.AspNetCore\Middleware\ApiKeyEnforcerMiddleware.cs:line 78
   at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.<Invoke>g__Awaited|6_0(ExceptionHandlerMiddleware middleware, HttpContext context, Task task)

That is the error you re suposed to get when you do a GetByID and the record isn’t found this normal epicor behavior.

If you are getting that error for absolutely everything is your DB empty?

Thank you Jose.

I am one of the under trained trying to understand what will happen in the new system.

The next question is “What is doing this GetByID?” if all I am doing is logging in.

Or clicking Order Entry.

I am only one user in this test system. Do I now expect to have thousands of runtime errors every day when I turn users loose in an updated environment?


A lot of epicor including the menu is stored as a database record so if those menu items are missing and it’s expecting to find them it’s going to be mad. Sounds like DB corruption to me, but just a guess

No that shouldn’t be the case sorry I may have fired off a little soon. getById does in fact do this as matter of course but it shouldn’t happen everywhere all at once.

Sounds like your DB may be lacking some records, or the account taht runs the Epicor Instance doesn’t have the appropriate permissions to query the records.

1 Like

Thank you. I needed something to point my IT guys at.


The database is not empty, as I have been testing for over a month. There is something basic that we are overlooking.


That Error should not be preventing you from logging in or anything. It is typically seen on the backend on 2022.1, The GenXData Error has been present also in older versions typically hidden inside ServerLog.

Epicor is simply logging it verbosely, they should obviously fix it at some point, its noise.

Happened on old versions too on WCF with GenXData it just never showed up in Event Viewer :slight_smile: but now since they are running on .NET Core you notice it in Event Viewer.

PS in mine I do have a BPM but even without it, it does it – I load in Process Overrides, i’ve seen this when its looking for a Personalization, Customization or something in the Cache mainly. But in 2022, it does it whenever I open any Kinetic Form

Maybe @pferrington can shut the noise off, I get like 200 a day in production. Harmless, but noisy.

1 Like

Thank you

That is actually what both of my own support said.

“Epicor is always fixing stuff, maybe it is normal.”


“Maybe it doesn’t slow anything down”

My education is now complete.

Learn how to filter this, or - Stop looking at error logs.


I actually think we have in… 11.2.100? Also known as 2022.1 but I’m not sure. We definitely resolved a bug related to this. We have similar concerns raised about token time out errors. The token one annoys me because the standard recommended practice for tokens involves the server throwing an exception as a standard business process (token expired) so the client knows to get a new one. But that clutters server logs with these sorts of errors.

1 Like

That is the version we are testing on. 11.2.100 and Kinetic 2022.1.8 per the About Kinetic.
I will continue to stick my head in the sand.