Windows 10 will randomly terminate the application

[Miro Hlozka 0]

Hi,
I would like to ask you not to look at the problem I am solving now. Maybe you have already met something similar and you will be able to advise me.
2 different applications have been running on Windows XP for many years and also on - without any problems.

1.) When switching to Windows 10, Windows 10 will randomly terminate the application after any time without any error message. Both applications are on different PCs with different motherboards and with Windows 10 professional.

2.) Applications are written in C ++ Builder 5 and use ComPort library components by Dejan Crnil and Brian Gochnauer

3.) Application1 communicates via 3 to 5 serial ports, application 2 communicates via 7 serial ports

4.) Application 1 runs continuously and windows 10 professional closes it after a few days from the start of the application - - the time of running the program before it closes with windows is different. Now I have increased the PC memory from 8 to 16 GB and maybe it helped - but it has to be deployed in a real environment with the customer and then they will see.

5.) Application 2 runs for 16 hours. Windows 10 professional closes it after about an hour, sometimes after a few hours from the start of the application - the time of running the program before it closes with windows is different. Increasing the PC memory to 64 GB did not help here

6.) In the appendix I attach the AppCrash report for application 2 how it was pulled out by the system.

Well thank you

Miro Hlozka

Report.wer

Report1.wer

Report2.wer

[A.M. Hoornweg 144]

"Event type=Bex"  --> Buffer overflow exception.   

 

Most likely, the data written into a block of memory exceeds its size.  There are tools to track down such errors (like Eurekalog, FastMM4 etc). 

[Lars Fosdal 1792]

Eurekalog or MadExcept would both be good choices to get to the bottom of any leaks or buffer overruns.

[FPiette 382]

I would suggest to run the applications under the debugger.

One possibility is that WIN10 has different layout/structure than XP and a bug crashing some data structure can have zero adverse effect on XP while it crashes WIN10.

Since this happens after "some time", it is possible that some resource is exhausted and then cause the above mentioned unknown bug.

 

[tgbs 14]

Are these comports real rs232 or are they on USB? If they are via USB I would look at the Power settings.

[Miro Hlozka 0]

thank you for your answers. Not specified:
1. Serial ports are AXAGO - via PCIe bus. 2 pieces with 4x COM
2. in power seting, I have switched off the saving mode also for PCIe.
3. I tried to use MadExcept nothing reported. I simulated division by zero - MadExcept displayed an error and logged it. I'll try it with him again, should I cancel all my own exception handling? I have used MadExcept for the first time now, I have no experience with it.

[Miro Hlozka 0]

MadExcept is probably a very useful program 

This clarification:
1. serial communication runs in 7 threads for reception. 6 threads have the highest priority,
   1 thread has the idle priority. In some of these threads, it is also easy to acknowledge received messages ACK, NAK, CAN ...
2. The transmission and calling device is in the transmission threade with priority normal.

😊

 

 

[aehimself 396]

I'm not saying it is the case at you but when my 24/7 application was closing unexpectedly it was always

1, Memory corruption

2, Improper thread object access / synchronization

3, In some cases memory / handle leak

 

I found that if the code gets to a really messed up state no exceptions are raised when something happens (no more AVs), the program simply halts. My guess is somewhere in the stack... but I'm far away from this proficiency to be able to tell.

I hope you have a test environment. Launch your application and set up performance monitors for memory and handle usages. I guess on a test machine only 1 serial port will be used, so give it 5x - 7x time, then extract your log and create a graph. If a value steadily increases - that CAN be your issue.

 

For memory corruption, doublecheck your Move-s. I even wrote an own move procedure which in debug builds raises exceptions if I'm overflowing an area (I'm mostly using TBytes - that's how I know the limits). PChar reservations can cause this too - always reserve the memory for (Length(String) + 1) * SizeOf(Char).

Thread things can be the hardest to find out, especially if they happen randomly. As performance is usually not crucial I tend to use a synchronized access to everything, that's why I have a generic TAtomicValue<T> class, which is handling the locking and unlocking for me. I'm using this instead of every simple value in the thread, plus inside every class which the thread allows external access to.

Detecting memory or handle leaks is the worst. Build a test app and run each and every method 1.000.000 times. Whenever said value is increasing, something will be wrong there (also take into account that it CAN be inside a component, not necessarily your code). Or, simply purchase DeLeaker (or something similar). When I joined my current company it became a must-have; after I realized the memory management of our codebase was as messed up as the first applications I wrote. Took me more than a year to get rid of them (p.s.: I'm still wondering how noone recognized this flaw before...)

 

"Happy" hunting. I wish you'll have your "ohgoddammit" moment soon.