Bug Description

When I first started OpenLP it crashed while the splash screen was shown - access violation in msvcr100.dll (-> Visual Studio 2010 runtime library) with some Qt DLLs above it in the callstack (according to the then attached debugger). OpenLP apparently loaded the Qt DLLs from the PATH instead of using the local ones - I've got Qt 4.7.1 built with Visual Studio 2010 in the PATH. Since the other DLLs in the OpenLP folder are linked against msvcr90.dll and runtimes can't usually be mixed this seems to be the source of the problem...
Removing my Qt build from the PATH helps, but it would be better if OpenLP simply used the libraries installed with it.

Hmm, I suspect very few people are going to have Visual Studio 2010 built Qt libraries sitting in their path on their Church presentation laptops!

I don't have Visual Studio 2010, and have no plans to build Qt myself. We use PyInstaller to package up the exe, but I'm not sure I'd even know where to begin to look at how to resolve this problem. It would likely take a long time to investigate and that time might be better used elsewhere, and even then there is no guarantee we could fix it.
However please feel free to investigate the problem yourself, since it looks like you are in the best position to do so! :)

I think to resolve this it would be necessary change Pyinstaller bootloader to somehow manipulate its PATH environment variable and perhaps some .manifest files. Technically, it is a change in the C code.

Now I installed 1.9.6 on another computer (with Vista 32-bit) and got another similar error before the Qt-related one:
Before even the splash screen was shown, a popup came up:
"The procedure entry point "libiconv_set_relocation_prefix" wasn't found in the DLL "iconv.dll." (translated from German)
When I click ok, the splash screen is shown and after a few seconds the app crashes as described in the first post.

I've found an iconv.dll in "C:\ruby\bin", which is also in my PATH, so it's basically the same problem.

Hmm....I just removed all Qt libs and iconv.dll-copies from my PATH by temporarily renaming their folders to test this (there were a few more) - now I get the message that iconv.dll couldn't be found and OpenLP starts normally when I click ok. The iconv.dll really misses in the main folder, but it's in OpenLP/enchant. But the Qt DLLs are obviously all there and loaded correctly...

I've had another look at the call stack and I may have found the cause of the Qt problem: qgenericbearer4.dll is not part of the OpenLP build and therefore loaded from "C:\Qt\4.7.1\plugins\bearer\" (my Visual Studio 2010 build).
I don't really understand how, since it's not actually in the PATH, but the call stack shows that QtCore4.dll uses msvcr90.dll (and is therefore likely to be the one from the OpenLP folder) and only qgenericbearer4.dll calls into msvcr100.dll. Here's the full stack: http://pastebin.com/4csYfRc8

I don't know what all is installed on the above machines, but I don't even have qgenericbearer4.dll anywhere on mine and OpenLP runs fine. From what I can find, this dll appears in a "Windows Fedora" package of QT. I do not believe this Dll is required in a 'normal' install of WIndows.

I do have iconv.dll (located in the Openlp install directory - C:\Program Files (x86)\OpenLP\enchant ) but I don't see it in the OpenLP process list when the program is running. This may be due to the language set I am using (English) and the use of of the dll is not required.

The entire Enchant package (less python scripts) is specifically included in the Windows build. I am building using pyenchant-1.6.5.win32

OpenLP doesn't seem to need qgenericbearer4.dll to run, but if it is found, it is loaded. The Qt Bearer plugin isn't part of PyQt, so packaging with OpenLP wouldn't be easy (Could be added manually of course...). Perhaps the PATH environment variable could be deleted for the OpenLP process on startup (-> os.environ['PATH'] = ''). That should prevent any incompatible external DLLs from being loaded. My case may be special, but there are Qt applications that write their bin-directory into the PATH on installation (e.g. MiKTeX), so similar problems might occur.

With iconv.dll it's similar, but there the obvious fix would be to put it in the main OpenLP folder instead of OpenLP/echant. I also noticed that I don't get a popup on my Win 7 machine, when iconv.dll is missing (but it's also loaded when present in the main OpenLP folder or somewhere in the PATH).

> Karan, can you test if deleting PATH will help?
When I start OpenLP from the source, the problem doesn't occur, so I guess I'd have to make an .exe with PyInstaller to really test it. I tried removing PATH and all Qt environment variables in a command shell and then starting OpenLP from that shell, but it didn't work (still crashing), although Process Explorer showed that the variables really didn't exist for the OpenLP process.

> Could you please check if on your win 7 is set the environment variable QT_PLUGIN__PATH?
No, my only Qt variables are QTDIR, QT4DIR, QTDIR_DEBUG.

> I would like to get an evironment similar to yours.
My environment takes quite a while to set up, maybe you can get away with just the problematic DLLs: http://dl.dropbox.com/u/5464702/OpenLP_incompatible_DLLs.zip
It's the iconv.dll from my ruby installation and qgenericbearer4.dll within the Qt directory structure. I have the environment variables QT4DIR and QTDIR pointing to Qt/4.7.1, and Qt/4.7.1/bin in the PATH.
But I'm not sure anymore if the environment variables are even used - OpenLP even crashes when I remove all references to my Qt build (and reboot). And I found all plugin paths also in the registry (HKEY_USERS\S-1-5-21-2378048838-1455849807-2857485230-1000\Software\Trolltech\OrganizationDefaults\Qt Factory Cache 4.7).

(My full environment is: Ruby 1.8.6 (bin directory in the PATH), Qt 4.7 for VS2008 (http://qt.nokia.com/downloads/windows-cpp-vs2008), configured for Visual Studio 2010 (witht configure.exe in the main Qt folder, something like configure -platform win32-msvc2010 I think), then compiled by executing 'qmake', then 'nmake' in the Visual Studio 2010 Command Prompt. Perhaps it would be enough to just install it and replace qgenericbearer4.dll with my one....)

I also found that the Qt search paths can be overridden with a qt.conf file: http://doc.qt.nokia.com/latest/qt-conf.html
I tried putting one into the OpenLP folder with "[Paths]\nPlugins = qt4_plugins", but nothing changed.

I set QT_DEBUG_PLUGINS, but I don't know where I'd find the debug info...

I also tried your code snippet - the output was an empty list. Though I suspect something different might happen when the installed version is started, since OpenLP never crashes when I start it with Python (directly from trunk). Is the PyInstaller-Windows-Guide on the wiki still up-to-date? Maybe I'll making my own build with some PATH/libraryPath-testcode when I find the time...