C++ application exit error code 62097 - What does that mean? - c++

My program is exitting with code '62097' (or in hex 0xF291).
I know which DLL library is causing it, and I'm trying to figure out why it is messing up.
What does 62097 mean? How can I find out? I checked online, and as far as I can tell, generic Windows error codes don't go up to 62097.
Any other suggestions how I can go about debugging this problem?
I use Dependency Walker on the DLL that's causing trouble, but everything is fine except missing IESHIMS.dll, IEFRAME.dll, and SHLWAPI.dll (which usually are missing when I use Dependency Walker).
The library in question is a 3rd party library that I compiled myself - it's quite possible I compiled it incorrectly - how can I tell if that's the case?
The program refuses to run before it enters main(), but only if I use a class imported from the DLL. If I'm not using anything from the DLL, the program starts fine.
The program is technically "running", but in the background, before the code ever reaches me. It's not a constructor of a class, because I tried doing something like this:
dllClass *class = new dllClass;
And the same thing occurred before execution reached the 'new', so it can't be a constructor with an infinite loop or something like that.
It's running as a process, and is not "Not responding".
I'm using MinGW on Windows 7 32bit. What can I do to troubleshoot this?
I appreciate any insight you can offer; meanwhile I'm trying to follow up a few more possible thoughts hoping I can narrow it down further.

This library is made using Qt ? Because according to http://lists.qt-project.org/pipermail/development/2013-March/010157.html it the return code Qt uses when it kills a process.

Related

Is there a way to get the DLL Loader to inform me of missing DLLs?

This question has plagued me for years. Not strong enough to do anything real about it. Just a small thorn in one's side.
Why is it that if you start a program and have a missing DLL, you get a nice informative message telling you which DLL is missing? Yet, when you use ::LoadLibrary you just get a ERROR_MOD_NOT_FOUND.
Raymond Chen explains this a bit further here. To me this answers why there's a dialog box, and not an error code. But it doesn't explain the burning question -- "How can I know which DLL is missing?"
I'm aware that I could build this, similar to Dependency Walker. However, in order to do this you have to properly match the DLL search path order.
Is anyone aware of an easy way to get the loader to tell me what it couldn't find? I don't want the dialog, I just want the missing dependency.
Similar thread:
How to make LoadLibrary to show error dialog when there are missing dependencies

Execution error with a C++ application deployed with InstallShield (windows)

I have a simple C++ program (command line with Boost libraries) that I developed under Visual Studio Community 2013. I want to deploy it on other Windows computers, so I am testing InstallShield LE in Visual to do so (I am new with InstallShield). I added an InstallShield project in the current solution and I managed to create a setup.exe.
When I test it on another computer, setup seems OK but when I try the application, I have weird error:
MyProgramm.exe --help
Sends correct result (but it is not really interesting).
MyProgramm.exe -i InputDirectory -o OutputDirectory
Fails with a Windows displaying this message:
A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available.
What did I miss?
I built Release configuration only. How can I be sure that I have checked all the merge modules or InstallShield prerequisite ?
You will have to identify what is going wrong. Typically the symptom you describe indicates that an exception caused the process to terminate. One common source of such exceptions is misuse of an invalid pointer.
But why does it work on one computer and not another? Depending on the code it could be random incidental things. But as long as this repeats every time, it's more likely to be environmental. This could mean a missing data file, a missing registry key, a missing service, or a missing .dll dependency.
Because you can run the program at least one way, you know it's not a static dependency. If it were, you'd get a message about an inability to load some file or one of its dependencies. But instead in some execution paths you see a crash. So if it's a dependency, it's what InstallShield calls a dynamic dependency. I'm not personally a big fan of it (I'd much rather be told exactly what might be required), but there is a dynamic dependency scanning wizard that can help identify such files and include them into the project.
That will only help if the problem stems from something like this:
HMODULE hMod = ::LoadLibrary(TEXT("SomeFunky.dll"));
SOMEPROC proc = (SOMEPROC)::GetProcAddress(hMod, "SomeFunkyProc");
int result = proc(some, args);
Or maybe from a COM-related variant of that that looks something like this:
CComPtr<ISomeFace> spSomeFace;
HRESULT hr = spSomeFace.CoCreateInstance(CLSID_SomeFace);
hr = spSomeFace->SomeMethod(some, args);
The common problem here is that neither of these blocks of code verifies the function it's calling is safe to call. In the first case, proc (or even hMod) could be null; in the second, spSomeFace might not have been successfully created an instance. While the code can (and should) prevent these scenarios from crashing, fixing the crash will not get your application to actually do what it's supposed to, and you'll still have to fix the reason that the procedure, dll, or instance could not be initialized as desired.
It's also possible that you're missing a data file or registry key that at some point is being used in an incorrect fashion. For example, the code may assume a data file exists, build a pointer from data it reads, and fail to work correctly because the file wasn't available and thus the buffer it read into was never actually initialized.
So in short, to solve this, if it's not a dependency scenario that the dynamic dependency scanner can assist with, you may have to debug the code in question. You could try tools like Process Monitor and look for errors that involve your application shortly before the crash. If you have source and symbols, you could try running the program under WinDbg to figure out exactly what was crashing, and then try to figure out why it does so in one environment but not another. But from just the information you've already provided, there's nobody that can tell you the answer.

Qt5/c++ generating 'Corrupted shared library list' error during debug

I have a Qt5/C++ app which appears to be working fine, but when running in debug mode (GDB), this error pops up on the QT Creator console (stderr) - OCCASIONALLY!:
Corrupted shared library list: 0x7fffe8008e90 != 0x751e50
I can't find any reference to the cause, and I can't figure out what is triggering it (other that something to do with using a QLinkedList.) I tried switching to a QVector but sometimes the same error pops up.
What is this and how do I fix it? Valgrind says no memory corruption...so is this a false reporting issue? Or am I doing something wrong.
I've traced the above error to the last line (line 4) below.
Settings *programSettings = Settings::instance();
QString driver=programSettings->database_driver();
driver="QMYSQL"; // Override for testing
m_db = QSqlDatabase::addDatabase(driver);
This makes no sense to me...can someone explain why the QSqlDatabase::addDatabase line causes corruption? As well, why does the error ONLY appear when debugging...but not when running without gdb?
Based on the number of views there seem to be a lot of people with this issue. We pared the code down to a simple example and then reproduced the problem. The source of the problem is not user code, but Qt Creator itself. We can't go much further - just put up with it until a Qt Creator fix comes along.
It looks like you're writing over memory that doesn't belong to yourself. It looks like you're dereferencing a pointer that has an uninitialized value. Compile your application with all warnings enabled, and make sure you understand all of the warnings. After that you may need to start a code audit, after you minimize the code of course.

This application has requested the runtime to terminate it in an unusual way QT C++

I am developing a Fifteen Puzzle Game in QT C++. Game works sometimes fine and sometimes crashed during run. I don't know the problem. I looked into different forums and found different suggestions. Some say this error is due to missing dll etc.
A window appears with Error is below
Microsoft Visual C++ Runtime Library
This application has requested the runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
I solved the problem: Actually I was accessing a vector location which was not available. assert() helped me to troubleshoot. Thanks #DNT

How can I debug a program when debugger fails

I am debugging an Iphone program with the simulator in xCode and I have one last issue to resolve but I need help resolving it for the following reason: when it happens the program goes into debugging mode but no errors appear (no BAD ACCESS appears) and it does not show where the code fails. Putting some variables as global helps me to see their values to start pin pointing where the bug is but before I go into this fully I would like to know what techniques/tools you guys use to debug these situations.
If it helps Im debugging the following: I merged some code into the SpeakHere demo. The code was added in the C++ modules of the program (AQRecorder.h and .mm). I seem to have pinpointed the problem code in a function I wrote.
My favourite is always to add debugging code and log it to a file. This allows me so report any and all information I need to resolve the issue if the debugger is not working properly.
I normally control the debugging code by use of a flag which I can manipulate at run time or by the command line.
If the error is (and it probably is) a memory management issue, printing log entries is really not going to help.
I would reccomend learning how to use Instruments, and use its tools to track down the memory leak when it occurs rather than waiting until the application crashes later on.