What I got:
Server console 32bit application written in ANSI C (free open-source multiplayer game);
Application runs in Embarcadero C++ Builder 10.3 in 'Debug mode';
Server OS: Windows Server 2012 R2 64bit.
Sometimes there appears CPU load problem. Video demonstration of this problem: https://youtu.be/eyASiAUG2vI
(description of the video: I've paused IDE and went step-by-step with F7... then it become 'Process is not acessible' so I paused it again and went with F7 one more time).
It looks like a problem with the debugger. It creates too many threads for whatever reason and that clogs the CPU... Windows not able to create thread because it's in Windows kernel method "base threadinitthunk". "thread exit, thread start, thread exit..." and so on so the debugger creates so many threads Windows cannot deal with it. There is no multithread in the application except the debugger.
I've checked C++ Builder project options (screenshots: 1,2,3) and can't find there options for thread loader. I wonder, is there a setting for C++ Builder to limit number of threads? Or some other workarounds?
Thanks!
Apparently it was bug in the code. It's already fixed :) So debugger was innocent after all...
Related
I have a C++ application (it's built using Qt 5.8 library and works with PostgreSQL 9.5 database in case it's relevant). The application is build by MSVC 2012 compiler, is 64-bit application and both debug and release versions run normally on their own and under cdb debugger.
When I try to profile the running application by Visual Studio instrument (Analyze -> Profiler -> Attach), it seemingly hangs as soon as it tries to do something meaningful: simply resizing a window or clicking on checkboxes works, but any attempt to compute new values and write them to database never succeeds, as if control flow didn't return from some call.
When I stop the profiling, Studio marks as a "hot path" sequence of calls RtlWalkFrameChain->RtlpWalkFrameChain->RtlpLookupFunctionEntryForStackWalks->RtlLookupFunctionTable->RtlAcquireSRWLockShared.
RtlpWalkFrameChain has the biggest "exclusive samples" count.
Trying to filter data to exclude initial several seconds of run (until the apparent freeze) results in "No Call Tree Data Is Available" message.
I didn't manage to find any article or post with a similar problem.
The project is build in Qt Creator (I don't have a project file Studio would understand, so I can't run "normal" performance analysis).
OS is Windows 7, exact version of Visual Studio is 11.0.61219.00 Update 5.
Any idea on the subject would be welcome.
Upd: When I try to profile the application with Luke Stackwalker profiler, it aborts with the message ERROR: StackWalk64-Endless-Callstack!. The only relevant comment about the message I found is this Stackoverflow question. When I run application under cdb debugger and then try to profile it with Luke Stackwalker, the error message is the same, but subsequent pause in the debugger shows the proper (or at least believable) stack for all threads. For the working thread debugger points to a line of code inside system library and doesn't advance no matter what I do (once again, without profiling attempts the application runs normally, debugger or not).
I am running one .NET binary using mono on my Linux platform PC and it is working fine on process startup.
But when i moved my running GUI window to another window and get back to that windows at that time , My GUI Application goes into the hang state because i can not press any button on My GUI window.
I have also used all the optimization option step by step while running .NET binary using mono but still causes the GUI hang issue.
I have debug my .NET binary with some debugging options and found that whenever GUI window application goes into stuck condition at that GDIplus library code is running. so, it seems that there is something is going wrong into the GDIplus library.
does any one have idea what is happening here or any one have faced this issue before?
Please let me know if anyone need any more information and give valuable feedback as sson as possible.
I recently converted a mingw/cygwin build to a Visual C++ cl.exe build and upon initial testing found it crashes at launch. I then installed it in my developer environment to debug it, under which it runs just fine. My initial suspicion was that I was linking to a different DLL in that context, but examining both processes in both contexts with Process Explorer showed that they were using the same versions of the same DLLs.
Since I can't reproduce the issue with Visual C++ installed I installed the remote debugger on the client machine, but I can't manage to attach to the process quickly enough before it crashes. Is there a good way to go about doing this? This would be easy if I could launch the process under the debugger locally, but that doesn't look like a viable option here.
Any help would be greatly appreciated. Thanks for your time!
You should be letting the remote debugger start the debugee process on the remote machine.
I call a Delphi DLL (multithread sockets dll) file using PB, When the PB application form closed, it's doesn't terminated really, and it's still Stay in the task manager!!! Why? How can I release
the multithread sockets DLL after powerbuilder application terminated?
Thanks in advance for your reply !
A dll written in Delphi that is loaded by a powerbuilder application, that does whatever network communications it might be doing would not still be around if the Powerbuilder application had truly terminated.
In windows it is impossible that anything might be keeping your process alive after Powerbuilder terminated it, unless that thing is a thread inside the delphi DLL that is created by the delphi DLL.
I would suggest you monitor the threads that exist in your application, using the delphi debugger. You can start your powerbuilder application from your delphi IDE, by opening your delphi project (that is used to build the DLL) and setting the Project Run Options so that the powerbuilder application that gets run that loads the DLL, is the "executable" in the RUn -> parameters dialog in the Delphi IDE.
Now run the whole thing in debug (green arrow button in the delphi IDE toolbars) and open the Threads panel, and watch the threads starting up in the delphi application. If there aren't any extra threads started by the delphi DLL (say the powerbuilder main thread is the only thread you can see), then the Delphi DLL can't possibly be keeping your application open.
As it is, the most likely thing that's happening is your program is freezing (crashing) because of some basic problem either in powerbuilder or the DLL. Again, solving the problem is probably going to require you to do some debugging, both with powerbuilder and delphi. more information would help people to help you.
I have a WPF 4.0 application that I have compiled for x86. When running on 64bit Win7, I need to start up an on-screen keyboard, located in %windows%/System32/osk.exe. Problem is I can't do it- I get an error 'Could not start On-Screen Keyboard'.
I found this thread:
Unable to launch onscreen keyboard (osk.exe) from a 32-bit process on Win7 x64 which sounds exactly like my problem.
I used all the relevant bits from that post, but the error persists. And even worse, I managed to get a 32 bit version of osk.exe and when I try to start THAT I just get a blank error box- no message at all, just a red 'X'.
So I can't compile my app for AnyCPU (3rd party interop libs), and have read that that might not solve the issue anyways. I have also read that one workaround is to disable virtualization using Wow64DisableWow64FsRedirection, but that this is unsafe. Seems like a lot of effort just to run a little app :(
What can I do to launch this little thing from my app?
Wrapping the offending app in a exe compiled with AnyCPU works fine and seems to be the least painful approach.