This OperationContextScope is being disposed on a different thread

Just curious…has anyone run across a “This OperationContextScope is being disposed on a different thread than it was created” error message and can you explain what it means?

It seemed this error happened when my co-worker was running the Recalculate Part Low Level Codes - User Run Conversion in the Conversion Workbench. I believe what happened is that he checked this Conversion and ran it and then went to run another conversion immediately afterwards and because the Recalculate Part Low Level Codes checkbox was still checked, it ran it again along with the other conversion process. And that’s when this error popped up. So I would say it would be good if the checkbox(es) would CLEAR once Actions - Run Pending Conversions process has been submitted.

We were able to get this conversion process to run to completion successfully and we did not get this error when we ran it again, thankfully, but I’m just curious as to what it means if we ever do see it again. Just needed to satisfy my curiosity if anyone has any further information on it? :slight_smile: Thanks!

I get it all the time. For example If I open certain windows with the link from a BAQ gadget on my home screen and then close that window, I get it. It doesn’t seem to cause anything bad, but it would be nice to not get those, or fix the underlying cause.

1 Like

REALLY!? Very interesting…I tried a search for this error on epiusers.help but couldn’t find any reference to it so I wanted to start a thread in case anyone else ran into the same error and we could at least know what it was or what it might be caused by.

Yeah, I’ve seen this message too.

I know the underlying reason for what throws the exception but have not seen that since POC days of kicking the tires on WCF. If you are getting that, I’d open a ticket. Something is doing some multi threading and not handling dispose correctly.

1 Like

It looks like it has to do with a personalization, because if I open it with the base, or even my customization it doesn’t do it, but when I open it with a personalization (anyone’s, not just mine) it throws the error. (So I’m not going to open a case because they will just tell me to delete my personalization, even though there is no custom coding in it)

Could this be caused by having personalizations set up, and then adding things to the customization afterwords?

I tried exporting and re-importing the personalization, same error. It kind of sucks to have to redo the personalizations every time we make a change to the customization, luckily, there isn’t much on this screen that’s been changed, this time.

I’d open a ticket to nail down what is going on in that personalization.

Support doesn’t deal with customization though. They will say, “It works on base mode, so it’s not a support issue, but we can set you up with a consultant to look at your problem”. The first thing that do is ask you disable your BPM’s customizations and personalizations.

And I get that, they can’t handle all of the customizations and personalizations that people do out there. That’s why this forum is helpful because there are people that can help with the things that pop up.

I just got that for the system monitor on our Pilot database (along with it being SUPER pokey, like taking 2 minutes to open…). Have a help ticket in right now, and suggestion was to use Epicor64 (which fixed the out of memory issues). Interesting thought that it might be a personalization causing it… Will try there.

1 Like

I received this error as well today while importing a personalization.

1 Like

Interesting that you both saw this recently. Thankfully we haven’t run into the message since my initial post… What versions of Epicor are you on? We are on 10.1.600.16…not sure if that matters in this case but always good to note. Hope you figure something out, especially in the case of the pokey System Monitor, and if you do, please update us on your findings! Although it sounds like a lot of people associate it with a personalization…Thank you! :slight_smile:

We are on 10.1.500.35, but I have seen the error previously on 10.1.500.12

1 Like

So I just opened a ticket, because it’s still happening in 10.2.200.7. We’ll see what they come back with.

2 Likes

So I opened the ticket. They want to recreate it in their system. The customization is there because there are UD fields in the database. They would have to get all of those in their exactly right to make it work. They also want step by step instructions to recreate the personalizations. I don’t remember all of the things that have been changed. It usually minor stuff like display some extra things in the trees, add a couple of columns, re-order a couple of columns and move a field or two. BUT, it’s been done over time and I don’t know what exactly has been done, and I’ll probably miss something if I try to re-create it. If I did know all of the steps, I probably would just delete and start over, but I don’t which is why I want to figure out how to fix this one.

So I don’t know how to get service what they need to re-create the problem. I need help trying to figure out how to recreate the problem or look for things that would create this problem.

What else will service be able to help me with if I can’t get the exact steps to them? What kind of information do I need to get to them in order for them to help? @aidacra @Bart_Elia? This is usually where I get stuck and service tells me “we don’t support customizations” or “we can refer you to a paid consultant to help you”.

Also I should add, the job entry screen somehow fixed itself in the process of exporting the customization and personalization. No more error. But I get the same error in the engineering workbench, I tried to do the same things with those files, but the error did not go away.

Can you actually re-create the “OperationContextScope” error? Does it happen on every user personalization that is on that particular Customization? (If so, I would wonder if the Customization has changed and the Personailzations need to be deleted and re-created off of the new Customization.) What if you create a new very simple Personalization off of that customization and see if you can get the error to trigger?

You mentioned that it seemed to be coming from Personalizations because once you got rid of them you didn’t see the message. So does that mean that if you open up ONLY the Customization and try to trigger the message that you won’t get the “OperationContextScope” error?

I guess another test would be looking for a Customizaton that has a Personalization that isn’t getting the “OperationContextScope” error then try modifying the Customization in a test environment and then testing the existing Personalization against this newly modified Customization and see if you can trigger the message.

I just wonder if you aren’t correct in that the Customization was modified after the Personalization was created and the Personalization needs to be re-created off of the new Customization.

We always delete all Personalizations if a Customization gets changed dramatically. I just wouldn’t trust them. Personalizations are nice for fluff but I never wanted to give our Users the impression that they would stick around because in the past (E9 days) if a user ran into a quirky unexplainable issue on a form we’d usually have to delete their personalization to fix it. If someone is relying heavily on a personalization to do their job maybe that should be incorporated into the Customization?

Most of the time I have no idea what a user did to create their personalization and sometimes a personalization gets created for someone and they didn’t even know about it because they’ve turned off the prompt to ask whether they want to save the personalization and it gets auto-saved. (We only turn on the Personalization option for certain people of course.)

Have you looked at any Log Files? Or Tracing options?
Just my two cents but it might not even be worth that. :slight_smile:

Yes, this is correct. I do believe it’s in the personalization. Some of the things in the personolization can’t be set in the customization. (like tree settings for example).

I think all of the major things are set in the customization, it’s moving around tabs columns.

I didn’t really think of that, since the I’m not calling any BO processes when the error hits. How would I do this?

I did try to open it up as debugging in VStudio, but once you close a window (which is what I’m doing) it seems like it’s pretty hard to follow the code. I probably just need help being shown how to do it.

edit: So another small update. I did export my personalization so I could delete it and see if I could recreate it (and reimport if needed). I changed some things and no longer get the error.

Service also said that they have seen some things that gave errors in 10.2.200.7 that now do not in 10.2.200.8. So we are going to try to upgrade to .8 in pilot and see if that fixes it.

What I don’t like about that approach, is I still don’t know what is causing the problem… So I don’t know what to avoid in the future.

Oh, I see. And it triggers when you close the window…I honestly have no idea on that one. I guess better wait for the experts to respond. Sorry, I was more just trying to think of ways that could help with the testing and the triggering of the error in order to help support try to re-create it.

1 Like

No worries. I need help brainstorming ideas. Lord knows I word vomit in here all the time just to work through ideas.

1 Like

If i have 2 customizations that are called the same thing, but for different screens, will that cause a problem?

image

More interesting things I’m learning. Apparently when you run or verify a customization from Customization/Personalization workbench, it applies your personalization to it. I would think that it’s not supposed to do that. Does anyone else have any experience on whether it does that or not?