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.
Related
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...
I don't know how to debug a COM ATL C++ out of process exe server with Visual Studio 2015.
For a COM ATL DLL there is no problem, the breakpoints are automatically triggered when I call the COM dll. However when I try to debug an EXE server, the debugger didn't break. Indeed the exe server is only loaded at demand and the debug symbols of the exe server are not loaded when the client starts.
My client, that call the COM server, is Excel VBA (I have added the reference to the com exe, in the VBA editor, via Tools/References). To debug it, I set the path to Excel.exe in the Visual Studio Debug command and as argument I set the path to my xlsm file. Then I just call call the VBA code in Excel. It works for the com DLL but not for the COM Exe. I also tried by attaching VS to Excel and it didn't work.
I have found this post ( Windows COM - how to debug a COM server ), it seems this is caused by a elevation/permission issue, but I tried the proposed answer but it didn't works.
Does any one can help me with this ?
How do you debug an out-of-process com server ?
Is it necessary to attach a debugger to the client that consumes the EXE server (so in my case to excel) ?
It's tricky trying to debug an EXE server.
What I would do is modify the registry so that you are prompted to debug the EXE when it is loaded.
Here is the contents of an exported .reg file used to modify the registry:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\YourExeName.exe]
"debugger"="vsjitdebugger.exe"
Change YourExeName.exe to something more useful...
When your EXE server is launched, you will be prompted to launch a debugger or attach from a current running instance of a debugger. It is faster and better to already have a debugger running... When I say "debugger", a running instance of Visual Studio is fine.
A problem when trying to debug an EXE server is that when you set breakpoints and step through the code, you can exceed the COM timeout and then the EXE client calling your process will have a failed call due to timeout and it will just continue executing. When everything is in process, this is not such a problem. For an EXE, it might be helpful to have a lot more TRACE statements in your debug build in the area where you think you might have problems.
It is not strictly necessary to attach to the client process. Sometimes it is helpful, and sometimes not. It's obviously much more easier if you have the source code to the calling client process.
I want to use the task dialog in my VC++ application. I am able to create a task dialog successfully using either TaskDialog or TaskDialogIndirect, and it works fine in Vista. However, I want my application to work on windows XP as well, and since windows XP does not support Task Dialog, I have created a dialog of my own that I want to use instead in case the OS is XP.
So my code does something like:
if OS is Vista or higher:
Show TaskDialog
else
Show my own dialog
Now the application still does not work in windows XP. When I attempt to start the application on XP, I get the error "The ordinal 345 could not be located in the dynamic link library comctl32.dll".
This is possibly because the call to TaskDialogIndirect is there in my code, though the call is in an if block. While loading the application it attempts to locate the function in the comctl32.dll, and it does not find it since it is the XP version of the dll.
So my question is:
How do I code my application so that it runs successfully on both XP and Vista, and in case of XP show my own dialog box whereas in case of Vista and higher show the task dialog?
The problem is that your application has a dependency on those functions, a dependency that the OS loader tries to resolve at application start-up. But of course, those functions don't exist in XP, so the executable fails to load.
There are two ways around this. First, try delay-loading comctl32.dll. This should remove the load-time dependency and delay the resolution until the function is actually called. Then you just need to take care not to call it where it's not supported.
If that doesn't work, then you would have to bind to TaskDialog explicitly, via LoadLibrary and GetProcAddress. This way, you never explicitly mention the function in a way that the linker would know about, so you don't take a load-time dependency on it. That's a bit more work though, mucking around with function pointers.
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 am having a service which calls a C++ COM dll. The C++ COM dll causes some problem and the service crashes.
I couldn't figure it at what point the service crash. I used debugdiag. But it is not putting any crash dump.
Kindly let me know how I can debug a application crash. Or direct me to some good tutorials and tools.
Many thanks.
Attach the Visual Studio debugger to your service via Tools / Attach to process. You might need to check Show processes from all users in order to see your service in the list.