Great. Also thanks for letting me know.

Best regards

Hi.

The disadvantages of using the app.config (kb.opclabs.com/How_to_disable_prerequisites_boxing ) workaround are:

1. If you are using OPC Classic, Microsoft Visual C++ runtime has to be installed manually on the computer.
2. If you are using OPC Classic, OCP proxies/stubs must be installed manually on the computer.
3. If you are using OPC UA and let QuickOPC generate the application instance certificate for you, OPC Foundation CertificateGenerator must be installed manually on the computer (it is sufficient to have this for the first run of the application only).

See also opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...ml#Prerequisites%20Boxing.html .

The necessary links for these are under the Redist folder.

My principal recommendation is to contact the QLM Express authors and let them know about the stack overflow. It is possible that it is a bug on their side that they can fix easily.

Regards

Hello,

thank you, this is really interesting. Apparently, in the call stack there is no "our" code at all. What's involved is some QlmLicenseLib.dll assembly. That is not ours. Some Googling told me that it may be related to Quick License Manager (QLM) Express product, from soraco.co/support . Are you using that directly, or are you referencing some other library that uses it ?

The issue may be some conflict between us and them. In fact, as I can see they are probably hooking to AssemblyResolve event, I have already seen several bad implementations of such hook that can cause various issues, including StackOverflowException. For one, the handler must not throw, unless there is a problem with loading the assembly found; it must return null (and not throw) when the assembly is simply "unknown". Not all programmers get that.

Regards

Thank you - it looks like that you have achieved to break into the right state. But the screenshots don't give me the information I was looking for. This is because they are not of the Call Stack, but rather of the various variables.

What I was asking for was the window that you get after performing Debug -> Windows -> Call Stack.

Can you repeat the test?

Also note that the window's whole contents (which is going to be big, but not necessary) or its part (it will have repetitive sections, so just a handful of them is sufficient) can be marked and copied to the clipboard.

Many thanks
Best regards

Thank you. I cannot reproduce this, so want to ask you for some hep on your side again.
I would like to figure out what the call stack at the time of StackOverflowException. I know that this can be difficult, as these tend to terminate the process, but let's try. Can you please:

1. In Debug -> Windows -> Exception Settings, add the StackOverflowException to the first-chance exceptions that will break, under "Common Language Runtime Exceptions".

2. In Debug -> Options, check "Break when exceptions cross AppDomain or managed/native boundaries...".

3. In Debug -> Options, *uncheck* "Enable Just My Code".

4. In Debug -> Options, check "Use Managed Compatibility Mode".

If you now trigger the problem again, do you get a break into the debugger, and some usable info in Call Stack window? If so, please send it my way.

Best regards