I have one Delphi Windows64 Application compiled by RAD Studio 10.3.3 that hangs sometimes in the finalization part of the main form after the call of CheckSynchronize; at the real end of application (nothing is called behind).
With ProcessExplorer on Windows10 19.03 I can verify open threads on TMethodImplementationIntercept and gdiplus.dllGdiPlusStartup0x1c00.
I do not have implemented any own Gdi calls. The integration of Gdi seems to be caused by any used component or from Delphi functionality internally.
Is there a way to localize some reason for that hanging Gdi threads?
If I call some ShowMessage after CheckSynchronize the Application is terminating well. Like in the example below...
Untit MainForm;
....
initialization
finalization
CheckSynchronize;
TDialogService.ShowMessage('End');
end.
Without ShowMessage the Application is hanging on that threads, but not each time.
If I call the Application from RAD Studio in Debug Mode without ShowMessage it is also terminating well at any time.
Is there any idea for some helping activity?
Related
The app in question uses both native and managed code. The managed code provides just the UI layer while it links with a native dll which performs bulk of operations. The native dll links with some other static dlls. Now the issue is when I run the app it crashes non-deterministically. When I debug the app under managed code debugging, it shows that a particular function in the native code threw an "SEH" Exception. Stack trace just shows the current function. The error code that I get in the SEH Exception is EFAIL.
However the app runs fine every time under native debugger. The function which throws the SEH exception is single threaded. It doesn't uses any resources which may be accessed in any other thread. What could be the possible cause for this behavior? How should I go about detecting the origin of the exception in native code. Stepping-in under the debugger doesn't helps since the issue doesn't shows up when the app is running under the debugger.
I am using visual studio 2012.
Are you using DirectX?
SEH Exception occurres when DeviceContext is using from many threads
at the same time, because DeviceContext isn't thread safe.
Is there a way to create a crash dump file automatically on application crash (on Windows OS), same as if I could save with Visual Studio debugger attached? That is, I want to be able to debug my application in Visual Studio with automatically created crash dump files.
Update: Debug Diag 2.0 is now available. This release has native support for .NET dumps.
Yes it is possible using DebugDiag 1.2.
The Debug Diagnostic Tool (DebugDiag) is designed to assist in
troubleshooting issues such as hangs, slow performance, memory leaks
or fragmentation, and crashes in any user-mode process. The tool
includes additional debugging scripts focused on Internet Information
Services (IIS) applications, web data access components, COM+ and
related Microsoft technologies.
It even allows you to run crash/hang analysis on the dump and give you a nice report about the callstack and thread that are in sleep state (for hang dumps). It also allows you to take on the fly dumps too. The dumps taken by DebugDiag can be analyzed in DebugDiag, Visual Studio and WinDbg.
EDIT: The MSDN link to how to use DebugDiag is here.
Use SetUnhandledExceptionFilter to catch exceptions. And in this global exception handler, use MiniDumpWriteDump function to create a dump file.
There is a lot around exception handling this way, like you won't be able to catch all exceptions (exception from STL, pure-virtual function, abort C runtime call etc). Also, you may be in problem if more than one thread causes some exception. You either need to suspend all other running threads when you get exception in your global exception handler, or use some logic so that other threads won't interfere with your dump-generation code.
To handle all cases, you need to tweak around linker settings (like /EHsc flag), so that ALL exceptions can be handled by try-catch, enable debugging information even for release build so that .PDB is generated and you can get call stack. Use API hooking, so that C-runtime calls won't disable your global-exception handler and lot!
See these:
SetUnhandledExceptionFilter and the C/C++ Runtime Library
Own Crash Minidump with Call Stack
My only recommendation is you start with simpler approach, and don't bother about more complex scenarios. In short, just use SetUnhandledExceptionFilter, in a single threaded application, cause an Access Violation, and in global-exception-handler, use MinidumpWriteDump to create a MINI dump (i.e. without memory-dump).
I'm having a problem with a VB6 app locking up when it is shutdown via the Windows Restart Manager.
This is very visible when using the new Restart Manager support in Inno setup and even occurs with an empty VB6 project compiled.
When I've added logging to the QueryUnload and Unload event, I see the following sequence:
QueryUnload(vbAppWindows)
Unload()
QueryUnload(vbAppTaskManager)
After this, the VB6 process seems to lock up inside the VB6 runtime and the process calling the Restart Manager eventually times out and gives up.
A similar problem has been reported before buit with no sensible resolution.
There were discussions on this in 2007 on the Windows Application Compatability forums.
The proposed solution was to add this to the end of the QueryUnload event handler of your main form:
'For Vista Certification requirement.
'Handles TEST CASE 30. Verify the application is Restart Manager Aware.
If UnloadMode = vbAppWindows Then Unload Me
It seems that the VB6 runtime isn't handling one of the shutdown messages correctly and so the Restart Manager then sends a more forcable close message causing the runtime to lock up.
I have confirmed this fix with a fairly complex, multi process VB6 application and it all shuts down correctly with no obvious untoward affects.
I am attempting to debug an error while loading my x64 application and am receiving an "MyAPP has stopped working" immediately before the first line of code in main().
What I am wondering is why when I use the debugger in Visual Studio 2010 (myapp.vshost.exe process) I can step through the code just fine and everything appears to run.
Figured it out - ansering my own question for future reference.
The main application was being profiled by Application Verifier (x64) which was causing a stack overflow. As applications under test is set in the registry, I had completely forgotten that this was still set in the list of processes to test. Since the vshost process is using it's own .exe it was not being profiled... no crash!
I have a console application (written in VB6 ) which is behaving strangely on my machine. I kick it off from the command line and what should be a two minute job drops straight back to the prompt - if I run this on another machine the executable will sit and wait until the job finishes before returning control back to the prompt. If I check process explorer I can see that the executable is running as a background process and other than this strange background-ness is running as expected.
Any thoughts on why this could be happening? (Running on 32-bit Windows XP Pro SP3.)
It's totally unclear whether this is an application you wrote and have the source code for. If that's the case, you need to get in and start debugging. At the least, use OutputDebugString to send information about what's going on to any number of potential viewers. Taking that a step further, consider rewiring the app using the Console module I wrote, along with vbAdvance to recompile. This combination will allow you the full power of the VB6 IDE to debug within. No more guessing about what's going on.
Then again, if it's not your app, I'm not sure what VB6 has to do with it and wish you the best of luck trying to figure out what's up.
It sounds to me as though the app isn't being recognised as a console app on one of your machines. Console apps weren't officially supported in VB6, although there are some well-known hacks for creating them (particularly the free add-in vbAdvance). Possibly your console app is a bit unreliable? If Windows thinks your app is a GUI rather than a console app, it won't wait for it to finish.
As a pragmatic workaround: try launching with start /wait rather than just using the exename. That forces the command prompt to wait for the program to finish, whether it's a GUI app or a console app.
Sounds like an error is occurring that is being 'swallowed' by the application. Do you have the source code?
Errors in VB6 apps are often due to some COM component not installed and/or registered.
Download SysInternals Process Monitor and this will show up accesses to ProgIDs that fail (uninstalled/unregistered COM components).
Check out: Process Monitor - Hands-On Labs and Examples.
Have you checked permissions? Is the application accessing any network based resources?