I do not have a way to update the sysconfig file for everyone. I can wait until the next user complains, and then manually modify their sysconfig file, sure. But its not a solution.
And yes there are updates all the time. Even when there is nothing on the schedule, we find our systems are updated. Its unpredictable.
@aosemwengie1, Can you also try something else next time it pops up. ? There is another XML file next to this one. Can you try deleting that one instead and see if that fixes it too? Just wondering if it’s specifically the file is the issue, or just the presence of the file allowing certain code to run.
This is just mostly my curiosity here so if you don’t have time, I understand. If I had the problem myself I would do it.
Yep we are probably done with people logging on for today, but I expect we will have another batch tomorrow morning to deal with.
A post was split to a new topic: Backflush Stopped Working
Got one more. No that did not fix it. Even more interesting, I turned on trace logging in the user profile and no log file was generated at all. The only thing that appears in the event viewer is
The program SessionManagerServer.exe version 4.3.200.0 stopped interacting with Windows and was closed. To see if more information about the problem is available, check the problem history in the Security and Maintenance control panel.
Even more interesting, after I moved the original xml file out of that directory and got epicor to launch successfully, then I put the same file back again AND IT STILL LAUNCHED SUCCESSFULLY. So its not the file itself. Its like something needs to happen, maybe some kind if connection or authentication or I don’t know what. And once it does its fine. But something about the presence of that file is interfering.
experiencing the same here in 2024.2.6 just after we did upgrade. I checked my logs, and we did have (almost) the same issue in kinetic in 10.2.500 > case CS0001870204, although i can’t access the case anymore.
Authentcation would give you an error, so it is probably size of it that causes download of too much data, and maybe something wrong goes because of time it takes…
Why is it too much the first time and not the second?
I would guess the authentication has a timeout and and you don’t need a new token until that time passes?
For now we went old school and put a clear.bat file in the users C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp folder and a shortcut onto their desktops.
Kludge but it’ll get us working until the cause can be found and fixed
Security risk.
authentication is done on call start, so if token is valid at this point, it is fine.
Is it possible to set this this throttling so it’s set on startup? We could test poor network performance that way?
@Olga , is there a way to remove or expire the authentication without removing the whole cache? We could test putting back the bad file, and forcing the system to have to authenticate again and see if that replicates the issue.
Authentication is unrelated. MRU cache is loaded on client start. so you exit client, you lose the cache. Smaller setting value less data you need to load. why it would prevent homepage from showing something I cannot tell.
oh, and the setting you show are for browser, and this cache is inside smart client, so not affected by it.
We are still investigating the root cause of this issue, but it does not seem to be related to any changes that we made to the software itself.
One “solution” is to follow the procedure below to change some settings and clear out some data from the local client. We have not stopped our investigation and will be publishing a final solution as soon as we have one.
Change client *.sysconfig setting for MaxBOMRU and MaxClssAttrMRU to zero:
Clear the client cache per step C2b of KB KB0035493
We are cloud, I do not have a way to change everyone’s sysconfig files and in the past when I have asked support to do it, they have refused. We are already clearing the cache nonstop. More than 60 times since the upgrade. We typically only have to help users clear the cache once or twice a week, so this absolutely has something to do with the upgrade.
We do not have an answer yet, but we can now reproduce in house which we were unable to do before and we have a formal work around for the clients experiencing this.
I just want to take a moment and say that in my opinion epiusers.help, this thread and Alisa in particular were a key part of our getting to the reproducible point as quickly as we have.
Thank you all!
Thrilled to hear you have been able to reproduce it, thank you for that update!
No help from me, just coming in to say we’ve been seeing the same thing since upgrading to 2023.2.29 last month. It seems to happen more often with users who switch companies regularly, but we’ve had a few single company users as well
No this is nothing like 2023.2, we were on that version for 6+ months and had to only occasionally clear a user’s cache. On this release we are having many users who have to clear the cache every day. In retrospect, we did encounter the issue during the pilot testing, but didn’t realize it was a new issue because clearing the cache is such a normal and standard thing to have to do every now and then, and people were typically only going into pilot a couple times a week for testing. I should have taken the issue more seriously when we had several people who had to have the cache cleared more than once to access Pilot instead of blowing it off as just the standard issues we always have with the Epicor client. Then maybe this fiasco could have been avoided.