I just broke Creator (again)...

mzimmers

...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.

mzimmers

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?

mchinand

This post is deleted!

mchinand

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).

mzimmers

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.

mchinand

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.

mzimmers

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.

SGaist

Hi,

Did you try to delete the .pro.user file from your project and configure it again ?

mzimmers

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?

SGaist

I'd rather go with checking these setting of Qt Creator before that.

mzimmers

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?

kshegunov

My 2c:
Open the debugger log and see what went wrong with the startup.

mzimmers

@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?

mzimmers

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...

JKSH

@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 ;)

mzimmers

@JKSH heisenbug, eh? I wonder if these are most prevalent in Berkeley Unix systems:

esse est percipi