Solved I just broke Creator (again)...
-
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: