Maybe I missed it above but sinply to state the obvious, have you cleared client cache, the cache folder, as well as the cache in AppData?
Completely unrelated but maybe a shot in the dark related, we had the same base error message (just the pre-details box) recently for a few jobs in job entry related to the job scheduler. Are these users tied to employees tied to resources on a job or have active labor on a job? If so, are you able to make changes to the job without an error going off?
Good to see itās working, I will look at this more closely and see if I spot anything in the error.
Other obvious tips, recycle iis, restart app server, etc.
When you say cleared client cache, cache folder and cache in AppData do you mean on the server? This definitely feels server side since restarting the server fixed the issue. We did have a couple of users clear their cache but were still getting the error about every other time they opened the app.
Guys, I think I might have hit on a thread here with the same issue. Itās with Kinetic and slightly newer version but wondering if it could be a licensing setting or Named Pipes not being enabled on the SQL server. I did see errors related to Named pipes in the event log and the error that was happening that week was tied to licensing.
No I meant on the client - a lot of our log-in issues seem to resolve after we clear the two caches. Not sure if cache gets stored based on a setting in the client config file or if itās always static but ours ends up on the same level as this folder:
As well as this one on the C://Users/USER/AppData/Local
Edit: Probably wouldnāt have fixed it, but those are always my first steps personally when troubleshooting. I just wanted to make sure to get the obvious stated that it had been tried. Reading it, looks like youāre definitely onto something about the licensing acting up, if you read it bottom to top, it looks like a series of bad inputs were parsed out - OperationBoundInvoker failed, passing up session values up until there was a deserialize error (object came through null ultimately causing the exception). Almost seems like it failed to create an object, whatever object they use, for the client session data which probably holds licensing activity etc. Hopefully it was just a flukeā¦ although it seemed to affect quite a few clients at once so this is a little beyond my ability to guess at this point.
Here is my hypothesis at this time and I apologize that I am very green when it comes to Epicor. The client contacts the app server and the app server talks to the db server and db possibly trying to use Named Pipes. The app server had issues connecting to the db server via Named Pipes during our week of this problem, because the named Pipes activity was going over the public firewall rules and there wasnāt an explicitly defined allowed rule for Named Pipes.
Does Epicor 10.2.700 running on Windows 2019 app server and 2019 SQL Server with SQL 2017 still need Named Pipes?
