I am working on a Gui Qt application. When deployed with the right dependencies it can be run independently as mingw-release, mingw-debug, msvc-release, and msvc-debug. When debugging under Qt Creator the mingw-debug can be debugged. However debugging the msvc-debug gives a crash. The disassembler shows:
ntdll!RtlUserThreadStart:
0x7ff901ae0d30 sub rsp,48h
This happens with even the most trivial GUI application. I have tried several Qt versions. At present I am using VC 2015 and Qt 5.10. The debugger is part of the Windows SDK kit. I am running Windows 10.
Added on Dec 28:
I can step into the debugger. The crash occurs as soon as the GUI thread is invoked, like window.show();
Related
I'm using Qt Creator v8.0.1, Qt 6.3.2(MinGW 11.2.0 64-bit), open source version, to develop x64 Windows desktop program and I encountered an assert problem.
Usually, when debugging a program in Qt Creator, if the assert condition in the program is false, the debugger will automatically break at the assert code and we can view calling stack and variables value. If my development environment is on Intel + Windows laptops, which has always been like this.
Recently, I changed to a Mac book Pro M2, equipped Parallel Desktop 18, and installed Windows 11 (on ARM) in Parallel Desktop, and installed Qt Creator v8.0.1, Qt 6.3.2 MinGW 11.2.0 64-bit in windows 11(On ARM). Qt binary is x64 architecure. I debug a program in Qt Creator. If the assert in the program is triggered, I can't view the current function call stack and variable values like I can on Intel+windows environment. Instead, the following message will pop up:
enter image description here
After I click “Retry”, it pops up
enter image description here
It took me a long time to solve this problem，I think it may be that the Qt (x64) debugging function is not adapted well enough on the M2.
Here are some of my attempts:
I installed Visual Studio Community 2022 On ARM in Windows 11 (on ARM) in Parallel Desktop, and Debugging assert works fine in Visual Studio Community 2022.
According to the "(Press Retry to debug the application - JIT must be enabled)" on the dialog, I set Just In Time Debug in Visual Studio, but it doesn't work either.
I set up “GDB Extended” in Qt Creator but it doesn’t work. And it has a great negatively impact on the debugging speed.
I tried to install the Qt for Windows on ARM, bug MinGW 11.2.0 64-bit kit was not supported. (https://doc.qt.io/qt-6/windows.html)
Does anyone know the reason for this problem? Or give some ideas. Thank you.
I have built a C# and GTK# program with Mono on Linux, and now I'm trying to run it on Windows 10. To see if I can get anything to run at all, I'm trying the HelloGTK example from the MonoDevelop documentation: http://www.monodevelop.com/documentation/stetic-gui-designer/
On the Windows 10 machine, I first tried installing Mono (32-bit), and running the application from the Mono command prompt as mono HelloGTK.exe, but it terminates instantly without any error message. I then tried uninstalling Mono and installing Gtk#, but with the same result: the application terminates silently when run from the Windows command prompt.
Could it be a .NET version mismatch, or missing .NET components? .NET is enabled (versions 3.5 and 4.6) in the Control Panel, but not all sub-items are checked. The program is built against .NET version 4.5.
I built a console application (with Mono on Linux) and it runs on the Windows machine without Mono installed. Is this enough for verifying the .NET status or could it still be an issue?
Could it be that the application does not find the GTK# libraries? Is there any way to verify the GTK# installation?
Could it be a GTK# version mismatch? The application is built against GTK# 2.12, and I installed 2.12.38 on the Windows machine, so I find this unlikely.
Any hints on how to troubleshoot this issue would be most appreciated!
forget all that:
native docker is now available on windows, so:
dockerize your app and make your image
copy to a windows box
run in docker
done
plus some details that probably need to be filled in. but docker works and will make your life infinitely easier where cross-platform issues are concerned.
The problem turned out to be in the code generated by the Stetic GUI designer which is included in MonoDevelop:
protected virtual void Build ()
{
...
this.Title = global::Mono.Unix.Catalog.GetString ("MainWindow");
With the above line commented out the application runs on Windows 10 with GTK# installed.
I want to have the same developing environment either in Linux and in Windows so I decided to use Qt Creator. But for some unknown reason I cannot trace my project in Qt Creator under Windows 7. I compile my program as DEBUG target, the resulting executable contains all debug info. After that I press F10 key to step over main function but instead of stepping it just brings program to run. Stepping into via F11 does the same thing.
Firstly I tried gdb shipped with MinGW but Qt Creator refused even to run it complaining that it should be Python capable. After that I have downloaded and installed gdb with Python support from
http://download.qt-project.org/development_releases/prebuilt/gdb/windows-7/qtcreator-gdb-7.4-MINGW32_NT-6.1-i686.tar.gz
as Qt Creator manual recommends but it just made that Qt Creator is able to start the debugger and nothing more, I could not do source level debugging anyway.
Qt Creator under Linux works fine with the same project, it traces, steps and shows the sources Ok. I run MinGW 4.8.1 and Qt Creator 3.1.1 under Windows 7 64bit and the same Qt Creator 3.1.1 version under Fedora Linux 64bit. How can I achieve source level debugging under Windows like under Linux I do?
The best thing is to use Visual studio express compiler and then install the windows debugging tools like specified here and configure qt-creator
Recent GDB builds shipped with MinGW are Python-enabled, and work out-of-the-box in Qt Creator. The link you found seems outdated.
I am working on a plug-in for an application. I have old development tools that have problems. My development tools are all from old 32 bit versions. CodeWarrior 6.7.and 8. I am running windows 7 pro 64 bit and having problems with the old tools. The CodeWarrior debugger will only work one time and I have to reboot before it will work again. It also has some problem using it. Break points stop working.
I switched to UeStudio from IDM but can not get a debugger to work. I created a project to use the compilers from Microsoft Visual Studio 10.0. UeStudio is supposed to use an integrated debugger. It downloads WinDbg.exe but it wont start up. The only WinDbg I found on Microsoft is from the Debugging Tools for Windows (x86) and (x64). It does not integrate with UeStudio. It starts up in a separate window. I have played around with it a bit but can not get it to load my DLL. I keep getting and error that it can not load my symbols (mismatching symbol file). I have set it to look were the '.pdb' for my plugin is located an doubled checked that it is correct. It's message names my DLL. I do not have symbols for the application. They do not supply one. I can load my source file and set Break points. But can not examine data.
Anybody get UeStudio debugging to work on windows 7? Or have any idea on debugging DLL on windows 7 cheaply.
I use OllyDebug.
OllyDbg
IDA is also very nice (paid)
I am trying to debug my app, which was compiled for 32-bit, native code, under VS2005. It crashes on a Windows 7 64-bit machine. I can't figure out how to get a call stack to see where it's crashing. I installed VS2005 on the Windows 7 machine, ran my app, got my crash -- and the dialog had a "Debug" button on it! Yay! I hit the "Debug" button, and it didn't do anything. How do I need to configure this?
I was wondering if I have to be running a Debug build? I copied my debug binaries over, but they won't run because of "side-by-side configuration" problem; apparently it does not have the debug ATL, MFC, CRT stuff that my 32-bit app wants to use. How do I fix that?
If the debugger won't start after the crash, just attach the debugger before the crash (if possible):
Start the debugger
Choose "Attach to process"
And select your process
The process will possibly hang for a few seconds while the debugger loads all the symbol information.
If your application now crashes, the debugger will automatically stop at the place of the crash. If this doesn't happen, check the Exceptions dialog and enable the relevant exceptions.
When installing VS with defaults, it will not install the 64 bit debugger. You must go back to the installer, select a custom install, and expressly select the 64 bit debugger.