A
atom0s
One of my fellow developers on a project of ours experienced a very strange bug yesterday/today that we can only assume/narrow down to potentially being a bug with OneDrive.
To give some context, our project is an injected hook into a video game to expand the game's feature set and add functionality. One of the features of our project is the ability to allow other developers to create plugins for our hook and load/unload them at runtime. Plugins are stored in a sub-folder to the root of our project called '/plugins/'. A small layout of the project would be:
/Ashita.exe
/Ashita.dll
/plugins/hardwaremouse.dll
When a plugin is loaded, we first set the current directly to the /plugins/ path based on where the user has installed the project. So for example, if installed into Program Files (x86), the SetCurrentDirectory call would be on the lines of:
::SetCurrentDirectory("C:\\Program Files (x86)\\Ashita 4\\plugins\\");
Then a LoadLibrary call attempt is made with just the plugin name, in this example 'hardwaremouse.dll'.
Following the load order rules of the system as seen here:
the module should be loaded after a few attempts at looking in the system directory. However, for this developer we logged and witnessed the following which is entirely not valid/following the load order mechanism of the system:
The first path is valid due to being an injected hook into another process, however, immediately after we see OneDrive being searched, which is not valid to the documented load order. This also does not even fall under valid if 'SafeDllSearchMode' is disabled (which it is not on this users system). The current directory is being force-set by us before calling LoadLibrary to the valid path of our projects plugin folder as mentioned above.
As you can see with the order here, it's completely broken and wrong. It begins with breaking at the OneDrive folder, then scans the proper system folders. Afterward, it scans a few PATH potential directories before scanning the system folders a second time oddly. Afterward, it continues to search PATH based directories before also bugging out and doing path variable expansion with the current directory appended to the start. This looks completely broken/wrong and does not follow the load order documentation at all, no matter what setting setup used.
Upon restarting the users system, the load order is fixed and instead, we see the valid order be followed here:
The only thing we can assume from this is that OneDrive is causing issues, potentially due to:
The user was not actively using OneDrive at the time, although it is on/enabled.
There was no file sync pending with OneDrive.
Restarting just the application did not resolve the issue while the load order was broken due to this bug.
This user has never experienced this issue with our project until recently updating to Windows 20H2.
Continue reading...
To give some context, our project is an injected hook into a video game to expand the game's feature set and add functionality. One of the features of our project is the ability to allow other developers to create plugins for our hook and load/unload them at runtime. Plugins are stored in a sub-folder to the root of our project called '/plugins/'. A small layout of the project would be:
/Ashita.exe
/Ashita.dll
/plugins/hardwaremouse.dll
When a plugin is loaded, we first set the current directly to the /plugins/ path based on where the user has installed the project. So for example, if installed into Program Files (x86), the SetCurrentDirectory call would be on the lines of:
::SetCurrentDirectory("C:\\Program Files (x86)\\Ashita 4\\plugins\\");
Then a LoadLibrary call attempt is made with just the plugin name, in this example 'hardwaremouse.dll'.
Following the load order rules of the system as seen here:
Dynamic-link library search order - Win32 apps
You can control the specific location from which any given DLL is loaded by specifying a full path. If you don't use that method, then the system searches for the DLL at load time as described in this topic.
docs.microsoft.com
the module should be loaded after a few attempts at looking in the system directory. However, for this developer we logged and witnessed the following which is entirely not valid/following the load order mechanism of the system:
- C:\Program Files (x86)\PlayOnline\SquareEnix\PlayOnlineViewer\hardwaremouse.dll - (This is valid for the application directory since we are injected into another process.)
- C:\Program Files (x86)\Microsoft OneDrive\20.201.1005.0006\hardwaremouse.dll - Bug immediately presents itself afterward as OneDrive is being used as the 2nd searched path.
- C:\Windows\SysWOW64\hardwaremouse.dll
- C:\Windows\System\hardwaremouse.dll
- C:\Windows\hardwaremouse.dll
- C:\Program Files (x86)\Common Files\Oracle\Java\javapath_target_1622277218\hardwaremouse.dll
- C:\Program Files (x86)\Common Files\Oracle\Java\javapath_target_1622277218\hardwaremouse.dll
- C:\Program Files (x86)\Razer Chroma SDK\bin\hardwaremouse.dll
- C:\Program Files\Razer Chroma SDK\bin\hardwaremouse.dll
- C:\Program Files (x86)\Google\Chrome\Application\hardwaremouse.dll
- C:\Windows\SysWOW64\hardwaremouse.dll
- C:\Windows\hardwaremouse.dll
- C:\Windows\SysWOW64\wbem\hardwaremouse.dll
- C:\Windows\SysWOW64\WindowsPowerShell\v1.0\hardwaremouse.dll
- C:\Windows\SysWOW64\OpenSSH\hardwaremouse.dll
- C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common\hardwaremouse.dll
- C:\Program Files\NVIDIA Corporation\NVIDIA NvDLISR\hardwaremouse.dll
- C:\Program Files\dotnet\hardwaremouse.dll
- C:\Program Files\Git\cmd\hardwaremouse.dll
- C:\Users\Administrator\AppData\Local\Microsoft\WindowsApps\hardwaremouse.dll
- C:\Program Files\FileBot\jre\bin\hardwaremouse.dll
- C:\Program Files\PuTTY\hardwaremouse.dll
- C:\Program Files\Microsoft SQL Server\120\Tools\Binn\hardwaremouse.dll
- C:\Program Files\Common Files\Autodesk Shared\hardwaremouse.dll
- C:\Program Files\Microsoft SQL Server\130\Tools\Binn\hardwaremouse.dll
- C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\hardwaremouse.dll
- C:\Program Files\FileBot\hardwaremouse.dll
- C:\Program Files (x86)\Ashita 4\plugins\%SystemRoot%\system32\hardwaremouse.dll
- C:\Program Files (x86)\Ashita 4\plugins\%SystemRoot%\hardwaremouse.dll
- C:\Program Files (x86)\Ashita 4\plugins\%SystemRoot%\System32\Wbem\hardwaremouse.dll
- C:\Program Files (x86)\Ashita 4\plugins\%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\hardwaremouse.dll
- C:\Program Files (x86)\Ashita 4\plugins\%SYSTEMROOT%\System32\OpenSSH\hardwaremouse.dll
- C:\Users\Administrator\.dotnet\tools\hardwaremouse.dll
- <System deemed the LoadLibrary call failed with error 126 at this point.>
The first path is valid due to being an injected hook into another process, however, immediately after we see OneDrive being searched, which is not valid to the documented load order. This also does not even fall under valid if 'SafeDllSearchMode' is disabled (which it is not on this users system). The current directory is being force-set by us before calling LoadLibrary to the valid path of our projects plugin folder as mentioned above.
As you can see with the order here, it's completely broken and wrong. It begins with breaking at the OneDrive folder, then scans the proper system folders. Afterward, it scans a few PATH potential directories before scanning the system folders a second time oddly. Afterward, it continues to search PATH based directories before also bugging out and doing path variable expansion with the current directory appended to the start. This looks completely broken/wrong and does not follow the load order documentation at all, no matter what setting setup used.
Upon restarting the users system, the load order is fixed and instead, we see the valid order be followed here:
- C:\Program Files (x86)\PlayOnline\SquareEnix\PlayOnlineViewer\hardwaremouse.dll
- C:\Windows\SysWOW64\hardwaremouse.dll
- C:\Windows\System\hardwaremouse.dll
- C:\Windows\hardwaremouse.dll
- C:\Program Files (x86)\Ashita 4\plugins\hardwaremouse.dll
- <System stops load attempt; deemed successful and found.>
The only thing we can assume from this is that OneDrive is causing issues, potentially due to:
- A pending OneDrive core update.
- A recent update to OneDrive in the Windows 20H2 update that is broken/bugged.
- An issue/error inside of OneDrive (or some related driver) causing the load order to bug out/break.
The user was not actively using OneDrive at the time, although it is on/enabled.
There was no file sync pending with OneDrive.
Restarting just the application did not resolve the issue while the load order was broken due to this bug.
This user has never experienced this issue with our project until recently updating to Windows 20H2.
Continue reading...