Qt Application loading Qt DLLs from OneDrive installation
-
There is more than one way a Windows installation can make an seemingly independent directory actually live under the Onedrive yoke.
Where do you think your "own software installation" is?
Where is the user's OneDrive/<version number>/ installation directory? What does <version number> refer to?What is the current working directory of the running executable? Windows will load a DLL from the current working directory if present (nothing to do with PATH).
@SGaist I now have a ProcessMonitor capture from the user and am able to examine the environment - the OneDrive folder is definitely not on the PATH. The path to the QT installation folder is very early in the PATH. This is where I would expect the Qt DLLs to be picked up from.
@ChrisW67 The software is installed under a common root directory in C:\ for all of my company's products. Elsewhere under that root directory is Qt 5.9.6, which is used by a number of different products in the company installation. The 'bin' directory of the Qt package (where the Qt DLLs reside) is on the PATH. My software also has a qt.conf that lives in the same directory as the executable and points into the common Qt 5.9.6 installation.
The user's OneDrive installation folder (i.e., the place the OneDrive client is installed) is
C:\Users<username>\AppData\Local\Microsoft\OneDrive\21.150.0725.0001I believe 21.150.0725.0001 in this path refers to the OneDrive version. This is the directory that contains OneDrive's Qt files.
The working directory of the executable is the user's home directory in this case (c:\Users<username>).
Going back to the Process Monitor output, I note that the first Qt DLLs the exe tries to load are Qt5Charts, Qt5Quick and Qt5Widgets. It looks for all of these in the same directory as my executable and this fails, as expected. It then tries the OneDrive directory. This succeeds for Quick and Widgets but not Charts. It also loads Qt5Gui from OneDrive. It continues to look for Qt5Charts and eventually loads from the expected location in my company installation.
What I need to understand is what is the mechanism whereby the OneDrive path takes precedence when loading these DLLs.
-
@SGaist I now have a ProcessMonitor capture from the user and am able to examine the environment - the OneDrive folder is definitely not on the PATH. The path to the QT installation folder is very early in the PATH. This is where I would expect the Qt DLLs to be picked up from.
@ChrisW67 The software is installed under a common root directory in C:\ for all of my company's products. Elsewhere under that root directory is Qt 5.9.6, which is used by a number of different products in the company installation. The 'bin' directory of the Qt package (where the Qt DLLs reside) is on the PATH. My software also has a qt.conf that lives in the same directory as the executable and points into the common Qt 5.9.6 installation.
The user's OneDrive installation folder (i.e., the place the OneDrive client is installed) is
C:\Users<username>\AppData\Local\Microsoft\OneDrive\21.150.0725.0001I believe 21.150.0725.0001 in this path refers to the OneDrive version. This is the directory that contains OneDrive's Qt files.
The working directory of the executable is the user's home directory in this case (c:\Users<username>).
Going back to the Process Monitor output, I note that the first Qt DLLs the exe tries to load are Qt5Charts, Qt5Quick and Qt5Widgets. It looks for all of these in the same directory as my executable and this fails, as expected. It then tries the OneDrive directory. This succeeds for Quick and Widgets but not Charts. It also loads Qt5Gui from OneDrive. It continues to look for Qt5Charts and eventually loads from the expected location in my company installation.
What I need to understand is what is the mechanism whereby the OneDrive path takes precedence when loading these DLLs.
@Bob64 said in Qt Application loading Qt DLLs from OneDrive installation:
What I need to understand is what is the mechanism whereby the OneDrive path takes precedence when loading these DLLs.
That would be a question for Microsoft, if the OneDrive path is not in the PATH.
-
@Bob64 said in Qt Application loading Qt DLLs from OneDrive installation:
What I need to understand is what is the mechanism whereby the OneDrive path takes precedence when loading these DLLs.
That would be a question for Microsoft, if the OneDrive path is not in the PATH.
@JKSH I think you are correct that this is not looking like a Qt issue. Depending on what the root cause is, potentially this might still be of interest to Qt developers working on Windows. I will report back if I get to the bottom of it.
Some things to note are that this has only recently started to happen, I have now had a second report from a different user, and nothing has changed in my application or in our Qt installation recently. I wonder if perhaps a OneDrive change is being rolled out that is causing this.
-
@JKSH I think you are correct that this is not looking like a Qt issue. Depending on what the root cause is, potentially this might still be of interest to Qt developers working on Windows. I will report back if I get to the bottom of it.
Some things to note are that this has only recently started to happen, I have now had a second report from a different user, and nothing has changed in my application or in our Qt installation recently. I wonder if perhaps a OneDrive change is being rolled out that is causing this.
@Bob64 said in Qt Application loading Qt DLLs from OneDrive installation:
Some things to note are that this has only recently started to happen, I have now had a second report from a different user, and nothing has changed in my application or in our Qt installation recently. I wonder if perhaps a OneDrive change is being rolled out that is causing this.
Hmm... that doesn't sound good. I'll keep an eye out for cases too.
Please do let us know if you uncover any clues
-
Hi, note that your qt.conf file is immaterial for this problem (it's used for plugins, translations etc. but not for loading .dlls)
Just guessing, but perhaps your user is logged in to OneDrive, so injects its shell dll (FileSyncShell.dll) into your process and puts its directory C:\Users<username>\AppData\Local\Microsoft\OneDrive\21.150.0725.0001 into the PATH setting of your process.
I think you need to do as @ChrisW67 says, copy all the Qt*.dlls into the same directory as your .exe file.
Or rebuild your app into a static version of Qt, i.e. with no dependencies of any Qt dlls. -
Hi, note that your qt.conf file is immaterial for this problem (it's used for plugins, translations etc. but not for loading .dlls)
Just guessing, but perhaps your user is logged in to OneDrive, so injects its shell dll (FileSyncShell.dll) into your process and puts its directory C:\Users<username>\AppData\Local\Microsoft\OneDrive\21.150.0725.0001 into the PATH setting of your process.
I think you need to do as @ChrisW67 says, copy all the Qt*.dlls into the same directory as your .exe file.
Or rebuild your app into a static version of Qt, i.e. with no dependencies of any Qt dlls.@hskoglund said in Qt Application loading Qt DLLs from OneDrive installation:
Just guessing, but perhaps your user is logged in to OneDrive, so injects its shell dll (FileSyncShell.dll) into your process and puts its directory C:\Users<username>\AppData\Local\Microsoft\OneDrive\21.150.0725.0001 into the PATH setting of your process.
Interesting. I'm logged into OneDrive but I don't think I have Qt DLL Hell.
My OneDrive installation (and Qt DLLs) are at C:\Program Files (x86)\Microsoft OneDrive\21.150.0725.0001 though; I wonder if that makes a difference.
-
@hskoglund said in Qt Application loading Qt DLLs from OneDrive installation:
Just guessing, but perhaps your user is logged in to OneDrive, so injects its shell dll (FileSyncShell.dll) into your process and puts its directory C:\Users<username>\AppData\Local\Microsoft\OneDrive\21.150.0725.0001 into the PATH setting of your process.
Interesting. I'm logged into OneDrive but I don't think I have Qt DLL Hell.
My OneDrive installation (and Qt DLLs) are at C:\Program Files (x86)\Microsoft OneDrive\21.150.0725.0001 though; I wonder if that makes a difference.
@JKSH said in Qt Application loading Qt DLLs from OneDrive installation:
My OneDrive installation (and Qt DLLs) are at C:\Program Files (x86)\Microsoft OneDrive\21.150.0725.0001 though; I wonder if that makes a difference.
Mine is the same and I do not see this issue. I have sent out an email to see if I can gather any clues as to whether there is any pattern to it.
-
Hmm, I just logged in to OneDrive to test it, and for me it installed in C:\Users\Henry\AppData\Local\Microsoft\OneDrive\21.150.0725.0001
In that directory there are one .exe file that loads Qt dlls: (OneDriveSetup.exe but that is the installer) and one dll: FileSyncViews.dll that also loads the Qt dlls.I tried to provoke Qt dll hell but to no avail :-(
I can see that Windows File explorer gets injected with that OneDrive dll when you log in to OneDrive, but a simple Hello World Qt program does not.Perhaps in your Qt app you have some browsing/file open support that causes OneDrive to be loaded (because it pretends to be an extra disk drive)?
-
Hi, note that your qt.conf file is immaterial for this problem (it's used for plugins, translations etc. but not for loading .dlls)
Just guessing, but perhaps your user is logged in to OneDrive, so injects its shell dll (FileSyncShell.dll) into your process and puts its directory C:\Users<username>\AppData\Local\Microsoft\OneDrive\21.150.0725.0001 into the PATH setting of your process.
I think you need to do as @ChrisW67 says, copy all the Qt*.dlls into the same directory as your .exe file.
Or rebuild your app into a static version of Qt, i.e. with no dependencies of any Qt dlls.@hskoglund Yes, you are correct about qt.conf. I should not have mentioned that.
I am logged into OneDrive myself and I do not see this issue. I have obtained from the affected user a Process Monitor log and am able to examine the environment of the process. The OneDrive directory is not injected into the PATH. There is some other mechanism going on somewhere.
Moving Qt DLLs or static linking would not be ideal. My company had a big push a few years ago to rationalise the third party dependencies of our different software products to reduce the overall footprint. Hence the common Qt package that all products are meant to share.
-
Sorry forgot to mention: ask your users with this problem to try to turn of their antivirus program, it could be the antivirus program that tries to browse all connected drives (including OneDrive) for malware and thus causes that OneDrive dll to be injected (just a guess)
-
@hskoglund it's an interesting theory about antivirus but I have never heard of anything like that before (AV injecting into DLL search path). In my experience, AV effects tend to be more intermittent and random than we are seeing and usually cause issues when applications are trying to access files at the same time as the AV.
Anyway, I am now seeing the same issue myself which in a way is good news as I might be able to make more progress on my own machine in diagnosing the issue.
-
@hskoglund it's an interesting theory about antivirus but I have never heard of anything like that before (AV injecting into DLL search path). In my experience, AV effects tend to be more intermittent and random than we are seeing and usually cause issues when applications are trying to access files at the same time as the AV.
Anyway, I am now seeing the same issue myself which in a way is good news as I might be able to make more progress on my own machine in diagnosing the issue.
@Bob64 said in Qt Application loading Qt DLLs from OneDrive installation:
Anyway, I am now seeing the same issue myself which in a way is good news as I might be able to make more progress on my own machine in diagnosing the issue.
Sounds like a way forward.
Please keep us posted!
-
Subsequent to my last post, I found that OneDrive had been updated on my machine the night before I started to see the issue.
One thing I did notice in Process Explorer was that OneDrive was appearing as a root process, with explorer as a child and then any Qt-based apps I launched were parented to explorer. I am not sure whether this provides an explanation as to why the OneDrive Qt DLLs were being preferentially loaded. As far as I am aware, the fact that a parent process has loaded a DLL from a particular location should not affect the child process, unless the load location is based on an inherited PATH (not the case here).
I found that a reboot was sufficient to resolve the problem. Following the reboot, I did not see the process structure described above on launching applications.
Although I have not been able to obtain definitive evidence, we suspect that the other people affected had recently received earlier OneDrive updates.
The conclusion appears to be that a OneDrive update without a reboot can leave ones machine in a somewhat odd state and, because the OneDrive client uses Qt, it can have a particular impact on Qt-based applications. The fact that it has happened to three different people in my organisation so far suggests that it could happen quite easily. Hopefully, a reboot will always resolve it if it happens.
