For a while now, my application has been randomly going into a sort of endless loop when returning from the form process to the browse process. Random because it only happens sometimes and also random because it happens on different browse/forms. The CPU time for this particular process is over 25%.
As a (temporary) workaround, I would like to create a service that periodically checks and kills a process when my application goes into an endless loop. There may be multiple instances of my application running, and of course I only need to kill the ones that are “hanging”.
So my question is: How can I find a process called “MyApplication” with a CPU time > 25%? Once I have the PID, killing the process is easy.
Probably, it’s better to find a reason why the process behaves wrongly. When your program goes to the problem, attach the debugger to its process using the PID obtained, for example, from the Windows Task Manager:
cladb -p <pid>
Then, open the threads list and stop all threads. If you have the SysInternal’s Process Explorer. you can find the TID of thread which eats the CPU time (right click on the line with your program’s process, choose the “Properties…” menu item and then choose the Threads tab in the dialog). In this case, you can stop only that thread by pressing the Ctrl-Space key. Then press the Space key to show the call stack of the thread you’re wanting to investigate. If the problem is in some infinite loop, usually it is somewhere in 1-3 procedures in the bottom of the Stack Trace debugger’s window.
Would be a good idea, but the problem is mainly on our server and just sporadically on my development machine, so no Clarion debugger available. But is is worth a try if it happens on my development machine.
The difference between cladb.exe and cladbne.exe is that the first one is linked with the manifest (also, programs use different icons). I do use my own variant of the which has no links to CLARUN and CLAASL. I have no problems with debugging (almost) any program using that debugger.
Thank you, that PDH_COUNTER_PATH_ELEMENTS will probably give what I am looking for. Unfortunate it is a bit beyond my skills to translate into Clarion and (I guess) using an API. Is there a more Clarion like example available?
I don’t believe that Windows defender is the cause. I know this sometime happend with TPS files, but this is MS SQL and my application folders are excluded from scanning.
But it is worth a try, so I stopped Windows defender and we will see what happens. (And no I won’t stop the Windows firewall, that would be not a wise thing to do.
Thanks, that solved it. I tried “PID” and “ProcessID” but not “IdProcess”
What is your personal telephone number. If my users have complaints they can call you…
No of course, this is my own risk, but I am willing to take it.
Just to add, as the problem that causes the freezes seems the same as the problems related to Translator class in C10/11, and that debugging the program was suggested, back in the day, it was hard to reproduce, and I dedicated some time debugging that problem but couldn’t find anything usesful and ended up just disabling it. Clarion debugger had some trouble entering in some places when it pops up the message whex.cpp and it is difficult when the problem starts in a place and blows up in other place (something usual) and worse when debugging on internal parts of the RTL or Winapi without source or references.
What I could add that when this problem ocurred, it appeared some minimize, restore/or maximize cannot recall, and cross buttons duplicated, like this image (taken from SV comp.lang.clarion newsgroup recent thread “Mystery fields in a browse” 2023-05-21 by Anthony, but in that case it was about Clarion 6.2)
I utilized that FauxMax template on our C6 app to get around that multiple-button bug. It wasn’t ideal, but at least we didn’t have that particular bug anymore.
There are no ideal solution for this problem because this is the bug in Windows implementation of MDI. Windows uses a global structure to hold information about MDI (active child, max state, menu of opened MDI child windows, etc.). Windows stuff accesses this structure without any synchronization. As result, for example, if two MDI child windows from different threads are trying to activate, information in that structure can become broken. About 1/3 of the RTL stuff working with WINDOWs is targeting to struggle with this problem.
C12 implements MDI child WINDOWs differently and all kinds of problem related to MS bug with MDI have to go away.
Here is the ZIP with C++ source and VS compiled EXE. This is the test program demonstrating numerous MDI problems. It was sent to MS ~20 years ago. All reported problems were confirmed but with notice that MS were not going to correct anything in MDI code. You can look at how the problem with multiple caption buttons manifests itself without Clarion RTL efforts to eliminate it by selecting the Maximize Test menu item. And feel the difference. MDI.zip (157.4 KB)
Thanks Alexey for the insights. But I wonder what could have changed on releases after Clarion 10.0.11897 that didn’t crashed according to Jack description.
I added steps to reproduce the problem or a similar one to PTSS 42978 on 2020-10-14.
And far as I can remember I didn’t have problems with freezing up my application in Clarion 9 build 10376. Once I upgraded to Clarion 11 build 13630 I got this issue (I think).
