xsharp.eu

Hi all,
finally I have the time again to test transporting our applications to X# after nearly one year of pausing!
Our application IOS has become very fast. I can't nearly see any differences of the Dotnet-Version compared to the Win32-Version. Great! It seems that you X#-Developers could speed up untyped methods/usual variable usage a lot!

What I am worried about: The program is exiting spontaneously sometimes without any errors. Running the program in the VS debugger does not show any hints, output to Procmonitor neither. The event log gives a hint, that the error happens in the Microsoft Dotnet assembly clr.dll. Does someone has ideas what can I try? I am using the latest VS-Compiler, the programs are compiled using the .netFramework 4.5.1.

Hi Arne,

In order to debug such issues, I would try to narrow down the problem, by omitting parts of it, until it does not happen again. So if the program has say 10 features, I would only enable/use 9 of them and see if the problem still happens from time to time. If it still does, I would stop using or remove from code something more and try again, until I see some hint.

I know, unfortunately this can be very time consuming, especially if the problem happens only very rarely. Speaking of that, how often does it happen? Every few minutes/hours/days running it? Maybe you have also monitored memory usage before it fails?

Hi Chris,
I am still trying to narrow down. It happens several times a day, sometimes already after few minutes, sometimes it takes longer. It happens not at the same place. Memory usage should be still ok, about 500 MB Virtual size according to Process Explorer.

I have made a dump file of the exception with Process dump from Sysinternals and analyzed it with "Windbg Preview" from Microsoft. It is a nice program. When loading the dump it automatically downloaded all symbol files for the Microsoft framework assemblies.
It seems that the crash happens in the Garbage collector and is an indication for memory corruption, see attached file.

Hi Arne,

This most likely points to some sort of a memory corruption. If application code contains any low level stuff (like casting incompatible types for example), introducing such issues is always a possibility. There could be many other reasons as well, maybe a threading issue, but without seeing the code or having more info about it, it's impossible to tell what's causing it.

If you do not have much success with narrowing down the problem, maybe you'd like to send use the whole code so we can review it as well and come up with ideas?

Thanks for the help. The next time I will still try to narrow down the issue.

Possibly these errors are related to the use of the formatted text control TECONTROL from Subsystems. Interesting that this effect did not happen one year ago with the old X#-Runtime. But this is perhaps the price for the better performance of the Runtime. We want to try with a new version of the control, as I have seen that the control sometimes generates exceptions direct in the control. So hopefully end of next week I can come with new information.

It is the TEControl for RTF and HTML input that makes the sporadic errors! According to the error messages and http://dotnetbeyond.blogspot.com/2010/0 ... n-clr.html
these can be "thread stack overrun errors". Unfortunately the TEControl is very important for us and as we use the VO GUI classes we cannot even substitute the control so easily.
The errors happen also without registering callback functions, just creating the control together with the window and assigning values and destroying the window and repeating this.

We have now the latest version of the control.

The errors happen also with the X#-Version of one year ago, only I did not realize it. I did not see this with the Vulcan Runtime, but I should have to test again, if this can help identifying reasons.

Do you have ideas, what I can try?

Hi Arne,

Any chance you can reproduce this in a standalone small sample? Let's say a small apps that opens several instances of windows with that control until in causes the problem? If you can, please send it to us so we can also have a look.

Hi Chris,

thank you for the offer. Yes, I have the chance to reproduce it. Only it is not a small sample. In these days I will limit the code as much as possible and send you the example.

Arne

Hi Chris,
I think that we have found the reason: When running the program with the debugger and enabling all exceptions I got exceptions of type "PInvokeStackImbalance" for certain of the DLL functions.
When looking at the import definitions for the functions exactly these functions contained the addition "STRICT" and not "PASCAL" although the original VO function contain "PASCAL". Now we have to look where in the conversion process these words have changed.

Arne