Thank you. I will test on Windows Server 2012 R2 as well, as tell you if I find a solution.

I almost can't believe it, but in 2 days or less, Microsoft has responded to my bug report with this:
"We have fixed this bug internally and the bug fix will be rolled out soon.", although the bug was not easily reproducible (see connect.microsoft.com/VisualStudio/feedback/details/1718934/...-result-when-ryujit-is-enabled ). I assume the fix will also work on Windows Server 2012 R2; if not, will tell them...

Best regards

Thank you. After my initial reply. I have edited the post a little, and suggested a different registry setting instead (because Microsoft does not recommend the original one - but has not explained why).

Can you please try both these settings in Windows 2012 R2 ?

Best regards

Update: Could not easily reproduce it in a small project. Reported to Microsoft anyway, with details of the debugging session in disassembly: connect.microsoft.com/VisualStudio/feedback/details/1718934/...-result-when-ryujit-is-enabled .

More to this issue: Current state of investigation leads to a conclusion that this is a bug in Microsoft .NET Framework 4.6. It appears to have something to do with the new JITting algorithm; similar to (but not the same) as nickcraver.com/blog/2015/07/27/why-you-should-wait-on-dotnet-46/ .

We have dug down to the assembly level, and found that with .NET 4.6 under 64 bits, certain 'ldiv' call in managed C++ (part of MFC HashKey(...) function) sometimes returns 0xCCCCCCCCCCCCCCCC, or zero, instead of the correct result. The incorrect result can then cause just about anything in the program. In our case, it throws an unhandled exception, because we are proactively checking some assumptions, and they get violated.

We have also found that the problem can be resolved by adding a DWORD 'useLegacyJIT' under the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework with value of 1.

(Changing the DWORD 'UseRyuJIT' under the same registry key from 1 to 0 also works, but is not recommended, according to github.com/Microsoft/dotnet/blob/master/docs/testing-with-ryujit.md ).


We will report the problem to Microsoft if we find a way to show it in a small stand-alone project.

Best regards

It is great that you have identified the conditions under which the problem appears. I have reproduced it now as well, by installing .NET Framework 4.6.

(Uninstalling .NET Framework 4.6. fixes the problem, but because it is an in-place upgrade, one needs to follow the uninstallation of 4.6 by an installation of 4.5).

I cannot tell at this moment what is the precise cause. We will investigate, and let you know here.

Thank you for reporting the problem and identifying the circumstances.

Best regards

I do not have any "real" suggestions how to deal with it, but couple of things that are worth trying, or answering:

1. Have you had any previous of QuickOPC ever installed on the machine? (trying to look for conflicts)

2. If the machine has not been rebooted after QuickOPC installation, please reboot it, even if the installation program has not asked for it.

3. When under the debugger, please obtain and post exception details - the call stack, and the InnerException, if any, and its call stack, and so on.

4. Any chance to do the same on a different machine?

Thank you, and best regards