Solved I just broke Creator (again)...
-
...seems that every so often, I do something that causes Creator not to properly build and/or run my application.
Using the maintenance tool, I uninstalled Qt and QtCreator, and reinstalled. Now when I try to run in the debugger, I get this:
--------------------------- Executable Failed --------------------------- During startup program exited with code 0xc0000135.
And when I try to run from Creator without debugging, I get this:
09:43:34: The program has unexpectedly finished. 09:43:34: The process was ended forcefully. 09:43:34: C:/Users/MZimmers/CD desktop apps/Qt projects/build-wifibutton_utility-Desktop_Qt_5_11_1_MinGW_32bit3-Debug/debug/wifibutton_utility crashed.
So...any ideas what I did wrong this time?
Thanks...
EDIT: I should point out that I can run a hello, world program from Creator just fine, using the same toolchain.
-
According to some Google results, the error message I'm getting is due to "missing" .dll files. What I don't understand is how the re-installation of Qt caused this.
- I didn't change my project file
- I didn't alter the default location of the Qt libraries
- I didn't alter the default location of the mingw libraries
- I didn't change my build environment (though I did uninstall old versions of Qt)
According to dependency walker, I'm not only missing the basic Qt .dlls (Qt5cored, etc.) but a bunch of MS files as well. What might I have done to screw this up so badly?
-
This post is deleted! -
QtCreator automatically adds the Qt bin directory for your selected kit, so that shouldn't be a problem (look at the Path variable for the 'Run' environment from QtCreators Project tab).
-
Run uses the build environment, whose PATH variable begins:
C:\Qt\Tools\mingw530_32\bin;C:\Qt\5.11.1\mingw53_32\bin;C:\Qt\Tools\mingw530_32\bin;
(Interesting that it would have the first entry twice.)
Those appear to be the correct directories.
-
You might want to delete everything in your build folder and rebuild (or change the build folder). Also, you can try running your program from a command shell. If it's a case of a missing dll, it will probably tell you that. Add the Qt bin folder to the path before running, I think this is correct in your case:
set PATH=C:\Qt\5.11.1\mingw53_32\bin;%PATH%
Edit: probably want to include the Qt\Tool\mingw530_32\bin directory too. I use MSVC so am not sure. -
I've tried deleting and rebuilding. It most definitely won't run from a command shell, nor would I expect it to, as the needed .dll files aren't co-resident with the binary. But I've always been able to run the app out of QtCreator until now.
I think my problem might be related to the selections I made with the maintenance tool. I'm now installing 5.11.1 and not selecting Mingw from the Tools section. Hopefully this will help.
EDIT:
No improvement. At this point, I'm fairly confident the problem isn't with my installation; it has to be a setting somewhere that got erased when I uninstalled older versions of Qt.
-
Hi,
Did you try to delete the .pro.user file from your project and configure it again ?
-
Hi SGaist - yes, I did...same results.
I'm wondering if there's something wrong with the maintenance tool...maybe I should try uninstalling, and downloading from the web site?
-
I'd rather go with checking these setting of Qt Creator before that.
-
I've reviewed the settings exhaustively. I realize I'm probably overlooking something, but it's as though I've inadvertently deleted a library reference or something similar.
I ran Dependency Walker, but evidently it's far too out of date to be useful here. Any ideas on how to isolate what changed when I reinstalled?
-
My 2c:
Open the debugger log and see what went wrong with the startup. -
@kshegunov thanks for the suggestion. Note that the app fails whether or not I use the debugger. But here are the last few lines of the debugger log:
NOTE: INFERIOR EXITED dState changed from InferiorRunOk(8) to InferiorShutdownFinished(14) [master] dState changed from InferiorShutdownFinished(14) to EngineShutdownRequested(15) [master] dCALL: SHUTDOWN ENGINE dPLAIN ADAPTER SHUTDOWN 15 dINITIATE GDBENGINE SHUTDOWN, PROC STATE: 2 <23python theDumper.exitGdb({"token":23}) >22^error,msg="During startup program exited with code 0xc0000135." dCOOKIE FOR TOKEN 22 ALREADY EATEN (EngineShutdownRequested). TWO RESPONSES FOR ONE COMMAND? dNOTE: INFERIOR EXITED dState changed from EngineShutdownRequested(15) to InferiorShutdownFinished(14) [master] dState changed from InferiorShutdownFinished(14) to EngineShutdownRequested(15) [master] dCALL: SHUTDOWN ENGINE dPLAIN ADAPTER SHUTDOWN 15 dINITIATE GDBENGINE SHUTDOWN, PROC STATE: 2 <24python theDumper.exitGdb({"token":24}) sExecutable failed: During startup program exited with code 0xc0000135. >&"python theDumper.exitGdb({\"token\":23})\n" dGDB PROCESS FINISHED, status 0, exit code 0 dNOTE: ENGINE SHUTDOWN FINISHED dState changed from EngineShutdownRequested(15) to EngineShutdownFinished(16) [master] dState changed from EngineShutdownFinished(16) to DebuggerFinished(17) [master] sDebugger finished.
I'm trying to approach this logically -- if I keep my .pro and .user files, what does a re-installation of Qt delete besides the platform and tool chain?
-
Well, batspit...for lack of a better approach, I put a hello world line in my main routine and commented everything else out. It worked. I gradually reduced the commented code, waiting for the error to recur, and...poof it just went away on its own.
"Solved" seems like a boastful term for this, but I'll mark it so anyway. Thanks to all who looked...
-
@mzimmers said in I just broke Creator (again)...:
Well, batspit...for lack of a better approach, I put a hello world line in my main routine and commented everything else out. It worked. I gradually reduced the commented code, waiting for the error to recur, and...poof it just went away on its own.
"Solved" seems like a boastful term for this, but I'll mark it so anyway. Thanks to all who looked...
Congratulations, you have found a heisenbug ;)
-
@JKSH heisenbug, eh? I wonder if these are most prevalent in Berkeley Unix systems: