Have look at the Internal FAQ, if you cannot find your answer here. Write to the OpenMS mailing list, if the problem persists.
Starting a (GUI) TOPP executable (like TOPPView or FeatureFinderCentroided) gives "The application was unable to start correctly (0xc0000005). Click OK to close the application"
When you run the tool in Debug mode and look where it crashes, you might acutally find it to be a very weird place - e.g. when creating a perfectly legal String from a QString:
QFileInfo fi(file.toQString());
return fi.path()
The reason this happens is usually: you've mixed DLL's from multiple runtimes (e.g. compiled with VS10 and VS9). This can easily happen, if you use your Qt (build with VS9) to link against your OpenMS (build with VS10). The loader will load VS9 and VS10 runtimes and will NOT tell you that they conflict. Instead, very weird things are going to happen. You can identify if you are affected by looking at the DLL's that are loaded via daisy-chaining - see either DependencyWalker's output or the 'output' window in VS when running the app from inside VS. It might read:
'MSSimulator.exe': Loaded 'C:\Windows\winsxs\amd64_microsoft.vc90.debugcrt_1fc8b3b9a1e18e3b_9.0.21022.8_none_4ec74c6b3093419c\msvcp90d.dll', Symbols loaded. 'MSSimulator.exe': Loaded 'C:\Windows\winsxs\amd64_microsoft.vc90.debugcrt_1fc8b3b9a1e18e3b_9.0.21022.8_none_4ec74c6b3093419c\msvcr90d.dll', Symbols loaded. 'MSSimulator.exe': Loaded 'C:\dev\qt-everywhere-opensource-src-4.7.1\bin\QtSqld4.dll', Symbols loaded.
As this was a VS10 build, the vc90 DLL's have no place here, but got loaded from the Qt4 DLL's. Fix is easy: recompile Qt (in this case) using VS10 and link against the new Qt.
Starting a (GUI) TOPP executable (like TOPPView or FeatureFinderCentroided) gives "Entry point not found"
This usually happens when your PATH% contains multiple versions of DLL's on which TOPP/OpenMS depends. Candidates are all QT (QtGui4.dll, QtCore4.dll, ...) or Xerces-C (xerces-c_3_0) libraries. Usually other external programms (Miktex, Mendeley etc) put their own binary directory (which contains these incompatible DLL's) before the contrib directory in your PATH%.
Solution: put the contrib directory at the very beginning of your PATH%. The other tools should be unaffected as DLL's are first searched in the path of the executable (where their DLL's should be as well). We do that for OpenMS as well, but only in the binary installer packages, not for the developer version.
Compiling the contrib or OpenMS, the windows.h header file seems to be missing!
Your error message might look like this:
c:\dev\contrib_build\src\bzip2-1.0.5\bzlib.h(79) : fatal error C1083:
Cannot open include file: 'windows.h': No such file or directory
This can happen if you are using the VS Express Edition or VS2008 on Win7 (other cases might be possible as well). The reason is that your INCLUDE environment path does not contain the system header windows.h, which is required by the contrib and OpenMS.
Solution: You need to download the Microsoft SDK for Windows 7 (or whatever your OS is). Make sure to select "Header Files" Section during install and make sure that the SDK's include path is in your INCLUDE environment.
gzip: stdin: invalid compressed data--crc error
| OpenMS / TOPP release 1.10.0 | Documentation generated on Thu Mar 7 2013 09:42:47 using doxygen 1.7.1 |