Nice catch! Thanks for the report. I guess the good part about this situation is that this allowed the user to realize that they had this unwanted software installed... (In reply to Chris H-C :chutten from comment #0) > Anything we can do about this? The user's taking actions to scrub the unwanted third-party software... but could we have prevented it from causing such grief in Firefox? I think that this bug highlights a potential general performance issue in our `patched_LdrLoadDll` code, which we use to send notifications about DLL loads. With our current version, if for some reason we end up *repeating failures to load the same DLL*, then we could be introducing a *lot* of overhead compared to standard `LdrLoadDll`, as we would be sending notifications for each failed attempt. Here is how I think this general problem manifests in this specific bug. The recurring call stack that attempts to load the library in the profile you shared is: ``` kernelbase!LoadLibraryExW user32!_ClientLoadLibrary ntdll!KiUserCallbackDispatch win32u!NtUserPeekMessage user32!_PeekMessage user32!PeekMessageW ``` According to [this blogpost](https://opcode0x90.wordpress.com/2007/05/11/user32__clientloadlibraryx/), `_ClientLoadLibrary` is responsible for loading the DLL that contains a hook that was set through [SetWindowsHookExW](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowshookexw), before calling into that hook. So, here is what I think happened: - PremierOpinion set some hooks using `SetWindowsHookExW`, on at least one specific event which occurs a lot in the GPU process; - every time this event occurs and gets dispatched by `PeekMessageW` in the GPU process, an attempt to load `pmls64.dll` occurs; - because the DLL is not loaded, this calls into our `patched_LdrLoadDll`, and our notification code runs, introducing some overhead; - the DLL load fails (likely because of the GPU sandbox released with Firefox 110, see bug 1809519), so the DLL stays not loaded, meaning that with the next event we will go through `patched_LdrLoadDll` again. So, to fix this issue, I think we should change how our `patched_LdrLoadDll` reacts to failure. It should either not introduce any overhead upon failure (so, no notification of failure); or it should at least introduce some kind of caching and refuse to attempt to load again a DLL that just failed to load or at least not not send new notifications about it. I'll try to reproduce the issue with my own hooks first.
Bug 1823412 Comment 1 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Nice catch! Thanks for the report. I guess the good part about this situation is that this allowed the user to realize that they had this unwanted software installed... (In reply to Chris H-C :chutten from comment #0) > Anything we can do about this? The user's taking actions to scrub the unwanted third-party software... but could we have prevented it from causing such grief in Firefox? I think that this bug highlights a potential general performance issue in our `patched_LdrLoadDll` code, which we use to send notifications about DLL loads. With our current version, if for some reason we end up *repeating failures to load the same DLL*, then we could be introducing a *lot* of overhead compared to standard `LdrLoadDll`, as we would be sending notifications for each failed attempt. Here is how I think this general problem manifests in this specific bug. The recurring call stack that attempts to load the library in the profile you shared is: ``` kernelbase!LoadLibraryExW user32!_ClientLoadLibrary ntdll!KiUserCallbackDispatch win32u!NtUserPeekMessage user32!_PeekMessage user32!PeekMessageW ``` According to [this blogpost](https://opcode0x90.wordpress.com/2007/05/11/user32__clientloadlibraryx/), `_ClientLoadLibrary` is responsible for loading the DLL that contains a hook that was set through [SetWindowsHookExW](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowshookexw), before calling into that hook. So, here is what I think happened: - PremierOpinion set some hooks using `SetWindowsHookExW`, on at least one specific event which occurs a lot in the GPU process; - every time this event occurs and gets dispatched by `PeekMessageW` in the GPU process, an attempt to load `pmls64.dll` occurs; - because the DLL is not loaded, this calls into our `patched_LdrLoadDll`, and our notification code runs, introducing some overhead; - the DLL load fails (likely because of the GPU sandbox released with Firefox 110, see bug 1809519), so the DLL stays not loaded, meaning that with the next event we will go through `patched_LdrLoadDll` again. So, to fix this issue, I think we should change how our `patched_LdrLoadDll` reacts to failure. It should either not introduce any overhead upon failure (so, no notification of failure); or it should introduce some kind of caching and refuse to attempt to load again a DLL that just failed to load or at least not not send new notifications about it. I'll try to reproduce the issue with my own hooks first.
Nice catch! Thanks for the report. I guess the good part about this situation is that this allowed the user to realize that they had this unwanted software installed... (In reply to Chris H-C :chutten from comment #0) > Anything we can do about this? The user's taking actions to scrub the unwanted third-party software... but could we have prevented it from causing such grief in Firefox? I think that this bug highlights a potential general performance issue in our `patched_LdrLoadDll` code, which we use to send notifications about DLL loads. With our current version, if for some reason we end up *repeating failures to load the same DLL*, then we could be introducing a *lot* of overhead compared to standard `LdrLoadDll`, as we would be sending notifications for each failed attempt. Here is how I think this general problem manifests in this specific bug. The recurring call stack that attempts to load the library in the profile you shared is: ``` kernelbase!LoadLibraryExW user32!_ClientLoadLibrary ntdll!KiUserCallbackDispatch win32u!NtUserPeekMessage user32!_PeekMessage user32!PeekMessageW ``` According to [this blogpost](https://opcode0x90.wordpress.com/2007/05/11/user32__clientloadlibraryx/), `_ClientLoadLibrary` is responsible for loading the DLL that contains a hook that was set through [SetWindowsHookExW](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowshookexw), before calling into that hook. So, here is what I think happened: - PremierOpinion set some hooks using `SetWindowsHookExW`, on at least one specific event which occurs a lot in the GPU process; - every time this event occurs and gets dispatched by `PeekMessageW` in the GPU process, an attempt to load `pmls64.dll` occurs; - because the DLL is not loaded, this calls into our `patched_LdrLoadDll`, and our notification code runs, introducing some overhead; - the DLL load fails (likely because of the GPU sandbox released with Firefox 110, see bug 1809519), so the DLL stays not loaded, meaning that with the next event we will go through `patched_LdrLoadDll` again. So, to fix this issue, I think we should change how our `patched_LdrLoadDll` reacts to failure. It should either not introduce any overhead upon failure (so, no notification of failure); or it should introduce some kind of caching and refuse to attempt to load again a DLL that just failed to load or at least not not send new notifications if that fails again. I'll try to reproduce the issue with my own hooks first.
Nice catch! Thanks for the report. I guess the good part about this situation is that this allowed the user to realize that they had this unwanted software installed... (In reply to Chris H-C :chutten from comment #0) > Anything we can do about this? The user's taking actions to scrub the unwanted third-party software... but could we have prevented it from causing such grief in Firefox? I think that this bug highlights a potential general performance issue in our `patched_LdrLoadDll` code, which we use to send notifications about DLL loads. With our current code, if for some reason we end up *repeating failures to load the same DLL*, then we could be introducing a *lot* of overhead compared to standard `LdrLoadDll`, as we would be sending notifications for each failed attempt. Here is how I think this general problem manifests in this specific bug. The recurring call stack that attempts to load the library in the profile you shared is: ``` kernelbase!LoadLibraryExW user32!_ClientLoadLibrary ntdll!KiUserCallbackDispatch win32u!NtUserPeekMessage user32!_PeekMessage user32!PeekMessageW ``` According to [this blogpost](https://opcode0x90.wordpress.com/2007/05/11/user32__clientloadlibraryx/), `_ClientLoadLibrary` is responsible for loading the DLL that contains a hook that was set through [SetWindowsHookExW](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowshookexw), before calling into that hook. So, here is what I think happened: - PremierOpinion set some hooks using `SetWindowsHookExW`, on at least one specific event which occurs a lot in the GPU process; - every time this event occurs and gets dispatched by `PeekMessageW` in the GPU process, an attempt to load `pmls64.dll` occurs; - because the DLL is not loaded, this calls into our `patched_LdrLoadDll`, and our notification code runs, introducing some overhead; - the DLL load fails (likely because of the GPU sandbox released with Firefox 110, see bug 1809519), so the DLL stays not loaded, meaning that with the next event we will go through `patched_LdrLoadDll` again. So, to fix this issue, I think we should change how our `patched_LdrLoadDll` reacts to failure. It should either not introduce any overhead upon failure (so, no notification of failure); or it should introduce some kind of caching and refuse to attempt to load again a DLL that just failed to load or at least not not send new notifications if that fails again. I'll try to reproduce the issue with my own hooks first.
Nice catch! Thanks for the report. I guess the good part about this situation is that this allowed the user to realize that they had this unwanted software installed... (In reply to Chris H-C :chutten from comment #0) > Anything we can do about this? The user's taking actions to scrub the unwanted third-party software... but could we have prevented it from causing such grief in Firefox? I think that this bug highlights a potential general performance issue in our `patched_LdrLoadDll` code, which we use to send notifications about DLL loads. With our current code, if for some reason we end up *repeating failures to load the same DLL*, then we could be introducing a *lot* of overhead compared to standard `LdrLoadDll`, as we would be sending notifications for each failed attempt. To fix this issue, I think we should change how our `patched_LdrLoadDll` deals with failure. We need to find some compromise between what we have now (having notifications at beginning and end of load is nice as long as loading works) and the fact that loading may be failing over and over. Here is how I think this general problem manifests in this specific bug. The recurring call stack that attempts to load the library in the profile you shared is: ``` kernelbase!LoadLibraryExW user32!_ClientLoadLibrary ntdll!KiUserCallbackDispatch win32u!NtUserPeekMessage user32!_PeekMessage user32!PeekMessageW ``` According to [this blogpost](https://opcode0x90.wordpress.com/2007/05/11/user32__clientloadlibraryx/), `_ClientLoadLibrary` is responsible for loading the DLL that contains a hook that was set through [SetWindowsHookExW](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowshookexw), before calling into that hook. So, here is what I think happened: - PremierOpinion set some hooks using `SetWindowsHookExW`, on at least one specific event which occurs a lot in the GPU process; - every time this event occurs and gets dispatched by `PeekMessageW` in the GPU process, an attempt to load `pmls64.dll` occurs; - because the DLL is not loaded, this calls into our `patched_LdrLoadDll`, and our notification code runs, introducing some overhead; - the DLL load fails (likely because of the GPU sandbox released with Firefox 110, see bug 1809519), so the DLL stays not loaded, meaning that with the next event we will go through `patched_LdrLoadDll` again. I'll try to reproduce the issue with my own hooks first.
Nice catch! Thanks for the report. I guess the good part about this situation is that this allowed the user to realize that they had this unwanted software installed... (In reply to Chris H-C :chutten from comment #0) > Anything we can do about this? The user's taking actions to scrub the unwanted third-party software... but could we have prevented it from causing such grief in Firefox? I think that this bug highlights a potential general performance issue in our `patched_LdrLoadDll` code, which we use to send notifications about DLL loads (begin, end). With our current code, if for some reason we end up *repeating failures to load the same DLL*, then we could be introducing a *lot* of overhead compared to standard `LdrLoadDll`, as we would be sending notifications for each failed attempt. To fix this issue, I think we should change how our `patched_LdrLoadDll` deals with failure. We need to find some compromise between what we have now (having notifications at beginning and end of load is nice as long as loading works) and the fact that loading may be failing over and over. Here is how I think this general problem manifests in this specific bug. The recurring call stack that attempts to load the library in the profile you shared is: ``` kernelbase!LoadLibraryExW user32!_ClientLoadLibrary ntdll!KiUserCallbackDispatch win32u!NtUserPeekMessage user32!_PeekMessage user32!PeekMessageW ``` According to [this blogpost](https://opcode0x90.wordpress.com/2007/05/11/user32__clientloadlibraryx/), `_ClientLoadLibrary` is responsible for loading the DLL that contains a hook that was set through [SetWindowsHookExW](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowshookexw), before calling into that hook. So, here is what I think happened: - PremierOpinion set some hooks using `SetWindowsHookExW`, on at least one specific event which occurs a lot in the GPU process; - every time this event occurs and gets dispatched by `PeekMessageW` in the GPU process, an attempt to load `pmls64.dll` occurs; - because the DLL is not loaded, this calls into our `patched_LdrLoadDll`, and our notification code runs, introducing some overhead; - the DLL load fails (likely because of the GPU sandbox released with Firefox 110, see bug 1809519), so the DLL stays not loaded, meaning that with the next event we will go through `patched_LdrLoadDll` again. I'll try to reproduce the issue with my own hooks first.
Nice catch! Thanks for the report. I guess the good part about this situation is that this allowed the user to realize that they had this unwanted software installed... (In reply to Chris H-C :chutten from comment #0) > Anything we can do about this? The user's taking actions to scrub the unwanted third-party software... but could we have prevented it from causing such grief in Firefox? I think that this bug highlights a potential general performance issue in our `patched_LdrLoadDll` code, which we use to send notifications about DLL loads (begin, end). With our current code, if for some reason we end up *repeating failures to load the same DLL*, then we could be introducing a *lot* of overhead compared to standard `LdrLoadDll`, as we would be sending notifications for each failed attempt. To fix this issue, I think we should change how our `patched_LdrLoadDll` deals with failure. We need to find some compromise between the features we want, and the fact that loading may be failing over and over. Here is how I think this general problem manifests in this specific bug. The recurring call stack that attempts to load the library in the profile you shared is: ``` kernelbase!LoadLibraryExW user32!_ClientLoadLibrary ntdll!KiUserCallbackDispatch win32u!NtUserPeekMessage user32!_PeekMessage user32!PeekMessageW ``` According to [this blogpost](https://opcode0x90.wordpress.com/2007/05/11/user32__clientloadlibraryx/), `_ClientLoadLibrary` is responsible for loading the DLL that contains a hook that was set through [SetWindowsHookExW](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowshookexw), before calling into that hook. So, here is what I think happened: - PremierOpinion set some hooks using `SetWindowsHookExW`, on at least one specific event which occurs a lot in the GPU process; - every time this event occurs and gets dispatched by `PeekMessageW` in the GPU process, an attempt to load `pmls64.dll` occurs; - because the DLL is not loaded, this calls into our `patched_LdrLoadDll`, and our notification code runs, introducing some overhead; - the DLL load fails (likely because of the GPU sandbox released with Firefox 110, see bug 1809519), so the DLL stays not loaded, meaning that with the next event we will go through `patched_LdrLoadDll` again. I'll try to reproduce the issue with my own hooks first.
Nice catch! Thanks for the report. I guess the good part about this situation is that this allowed the user to realize that they had this unwanted software installed... (In reply to Chris H-C :chutten from comment #0) > Anything we can do about this? The user's taking actions to scrub the unwanted third-party software... but could we have prevented it from causing such grief in Firefox? I think that this bug highlights a potential general performance issue in our `patched_LdrLoadDll` code, which we use to send notifications about DLL loads (begin, end). With our current code, if for some reason we end up *repeating failures to load the same DLL*, then we could be introducing a *lot* of overhead compared to standard `LdrLoadDll`, as we would be sending notifications for each failed attempt. To fix this issue, I think we should change how our `patched_LdrLoadDll` deals with failure. We need to find some compromise between what we want to be notified about, and the fact that loading may be failing over and over. Here is how I think this general problem manifests in this specific bug. The recurring call stack that attempts to load the library in the profile you shared is: ``` kernelbase!LoadLibraryExW user32!_ClientLoadLibrary ntdll!KiUserCallbackDispatch win32u!NtUserPeekMessage user32!_PeekMessage user32!PeekMessageW ``` According to [this blogpost](https://opcode0x90.wordpress.com/2007/05/11/user32__clientloadlibraryx/), `_ClientLoadLibrary` is responsible for loading the DLL that contains a hook that was set through [SetWindowsHookExW](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowshookexw), before calling into that hook. So, here is what I think happened: - PremierOpinion set some hooks using `SetWindowsHookExW`, on at least one specific event which occurs a lot in the GPU process; - every time this event occurs and gets dispatched by `PeekMessageW` in the GPU process, an attempt to load `pmls64.dll` occurs; - because the DLL is not loaded, this calls into our `patched_LdrLoadDll`, and our notification code runs, introducing some overhead; - the DLL load fails (likely because of the GPU sandbox released with Firefox 110, see bug 1809519), so the DLL stays not loaded, meaning that with the next event we will go through `patched_LdrLoadDll` again. I'll try to reproduce the issue with my own hooks first.
Nice catch! Thanks for the report. I guess the good part about this situation is that this allowed the user to realize that they had this unwanted software installed... (In reply to Chris H-C :chutten from comment #0) > Anything we can do about this? The user's taking actions to scrub the unwanted third-party software... but could we have prevented it from causing such grief in Firefox? I think that this bug highlights a potential general performance issue in our `patched_LdrLoadDll` code, which we use to send notifications about DLL loads (begin, end). With our current code, if for some reason we end up *repeating failures to load the same DLL*, then we could be introducing a *lot* of overhead compared to standard `LdrLoadDll`, as we would be sending notifications for each failed attempt. To fix this issue, I think we should change how our `patched_LdrLoadDll` deals with failure. We need to find some compromise between what we want to be notified about, and the fact that loading may be failing over and over. For example, we could stop sending notifications for any library that reaches a fixed number of failures to load; and we could introduce a new event for when a library somehow finally loads successfully but we didn't report the begin event because we assumed it would fail again. Here is how I think this general problem manifests in this specific bug. The recurring call stack that attempts to load the library in the profile you shared is: ``` kernelbase!LoadLibraryExW user32!_ClientLoadLibrary ntdll!KiUserCallbackDispatch win32u!NtUserPeekMessage user32!_PeekMessage user32!PeekMessageW ``` According to [this blogpost](https://opcode0x90.wordpress.com/2007/05/11/user32__clientloadlibraryx/), `_ClientLoadLibrary` is responsible for loading the DLL that contains a hook that was set through [SetWindowsHookExW](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowshookexw), before calling into that hook. So, here is what I think happened: - PremierOpinion set some hooks using `SetWindowsHookExW`, on at least one specific event which occurs a lot in the GPU process; - every time this event occurs and gets dispatched by `PeekMessageW` in the GPU process, an attempt to load `pmls64.dll` occurs; - because the DLL is not loaded, this calls into our `patched_LdrLoadDll`, and our notification code runs, introducing some overhead; - the DLL load fails (likely because of the GPU sandbox released with Firefox 110, see bug 1809519), so the DLL stays not loaded, meaning that with the next event we will go through `patched_LdrLoadDll` again. I'll try to reproduce the issue with my own hooks first.
Nice catch! Thanks for the report. I guess the good part about this situation is that this allowed the user to realize that they had this unwanted software installed... (In reply to Chris H-C :chutten from comment #0) > Anything we can do about this? The user's taking actions to scrub the unwanted third-party software... but could we have prevented it from causing such grief in Firefox? I think that this bug highlights a potential general performance issue in our `patched_LdrLoadDll` code, which we use to send notifications about DLL loads (begin, end). With our current code, if for some reason we end up *repeating failures to load the same DLL*, then we could be introducing a *lot* of overhead compared to standard `LdrLoadDll`, as we would be sending notifications for each failed attempt. To fix this issue, I think we should change how our `patched_LdrLoadDll` deals with failure. We need to find some compromise between what we want to be notified about, and the fact that loading may be failing over and over. For example, we could stop sending notifications for any library that reaches a fixed number of failures to load; and we could introduce a new event for when "a library somehow finally loaded successfully, but we didn't report the begin event because we assumed it would fail again and bring too much overhead". Here is how I think this general problem manifests in this specific bug. The recurring call stack that attempts to load the library in the profile you shared is: ``` kernelbase!LoadLibraryExW user32!_ClientLoadLibrary ntdll!KiUserCallbackDispatch win32u!NtUserPeekMessage user32!_PeekMessage user32!PeekMessageW ``` According to [this blogpost](https://opcode0x90.wordpress.com/2007/05/11/user32__clientloadlibraryx/), `_ClientLoadLibrary` is responsible for loading the DLL that contains a hook that was set through [SetWindowsHookExW](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowshookexw), before calling into that hook. So, here is what I think happened: - PremierOpinion set some hooks using `SetWindowsHookExW`, on at least one specific event which occurs a lot in the GPU process; - every time this event occurs and gets dispatched by `PeekMessageW` in the GPU process, an attempt to load `pmls64.dll` occurs; - because the DLL is not loaded, this calls into our `patched_LdrLoadDll`, and our notification code runs, introducing some overhead; - the DLL load fails (likely because of the GPU sandbox released with Firefox 110, see bug 1809519), so the DLL stays not loaded, meaning that with the next event we will go through `patched_LdrLoadDll` again. I'll try to reproduce the issue with my own hooks first.
Nice catch! Thanks for the report. I guess the good part about this situation is that this allowed the user to realize that they had this unwanted software installed... (In reply to Chris H-C :chutten from comment #0) > Anything we can do about this? The user's taking actions to scrub the unwanted third-party software... but could we have prevented it from causing such grief in Firefox? ~~I think that this bug highlights a potential general performance issue in our `patched_LdrLoadDll` code, which we use to send notifications about DLL loads (begin, end). With our current code, if for some reason we end up *repeating failures to load the same DLL*, then we could be introducing a *lot* of overhead compared to standard `LdrLoadDll`, as we would be sending notifications for each failed attempt.~~ ~~To fix this issue, I think we should change how our `patched_LdrLoadDll` deals with failure. We need to find some compromise between what we want to be notified about, and the fact that loading may be failing over and over. For example, we could stop sending notifications for any library that reaches a fixed number of failures to load; and we could introduce a new event for when "a library somehow finally loaded successfully, but we didn't report the begin event because we assumed it would fail again and bring too much overhead".~~ Here is how I think this general problem manifests in this specific bug. The recurring call stack that attempts to load the library in the profile you shared is: ``` kernelbase!LoadLibraryExW user32!_ClientLoadLibrary ntdll!KiUserCallbackDispatch win32u!NtUserPeekMessage user32!_PeekMessage user32!PeekMessageW ``` According to [this blogpost](https://opcode0x90.wordpress.com/2007/05/11/user32__clientloadlibraryx/), `_ClientLoadLibrary` is responsible for loading the DLL that contains a hook that was set through [SetWindowsHookExW](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowshookexw), before calling into that hook. So, here is what I think happened: - PremierOpinion set some hooks using `SetWindowsHookExW`, on at least one specific event which occurs a lot in the GPU process; - every time this event occurs and gets dispatched by `PeekMessageW` in the GPU process, an attempt to load `pmls64.dll` occurs; - because the DLL is not loaded, this calls into our `patched_LdrLoadDll`, and our notification code runs, introducing some overhead; - the DLL load fails (likely because of the GPU sandbox released with Firefox 110, see bug 1809519), so the DLL stays not loaded, meaning that with the next event we will go through `patched_LdrLoadDll` again. I'll try to reproduce the issue with my own hooks first.
Nice catch! Thanks for the report. I guess the good part about this situation is that this allowed the user to realize that they had this unwanted software installed... (In reply to Chris H-C :chutten from comment #0) > Anything we can do about this? The user's taking actions to scrub the unwanted third-party software... but could we have prevented it from causing such grief in Firefox? ~~I think that this bug highlights a potential general performance issue in our `patched_LdrLoadDll` code, which we use to send notifications about DLL loads (begin, end). With our current code, if for some reason we end up *repeating failures to load the same DLL*, then we could be introducing a *lot* of overhead compared to standard `LdrLoadDll`, as we would be sending notifications for each failed attempt.~~ ~~To fix this issue, I think we should change how our `patched_LdrLoadDll` deals with failure. We need to find some compromise between what we want to be notified about, and the fact that loading may be failing over and over. For example, we could stop sending notifications for any library that reaches a fixed number of failures to load; and we could introduce a new event for when "a library somehow finally loaded successfully, but we didn't report the begin event because we assumed it would fail again and bring too much overhead".~~ ~~Here is how I think this general problem manifests in this specific bug.~~ The recurring call stack that attempts to load the library in the profile you shared is: ``` kernelbase!LoadLibraryExW user32!_ClientLoadLibrary ntdll!KiUserCallbackDispatch win32u!NtUserPeekMessage user32!_PeekMessage user32!PeekMessageW ``` According to [this blogpost](https://opcode0x90.wordpress.com/2007/05/11/user32__clientloadlibraryx/), `_ClientLoadLibrary` is responsible for loading the DLL that contains a hook that was set through [SetWindowsHookExW](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowshookexw), before calling into that hook. So, here is what I think happened: - PremierOpinion set some hooks using `SetWindowsHookExW`, on at least one specific event which occurs a lot in the GPU process; - every time this event occurs and gets dispatched by `PeekMessageW` in the GPU process, an attempt to load `pmls64.dll` occurs; - because the DLL is not loaded, this calls into our `patched_LdrLoadDll`, and our notification code runs, introducing some overhead; - the DLL load fails (likely because of the GPU sandbox released with Firefox 110, see bug 1809519), so the DLL stays not loaded, meaning that with the next event we will go through `patched_LdrLoadDll` again. I'll try to reproduce the issue with my own hooks first.
(Edit: This comment is wrong/incorrect) Nice catch! Thanks for the report. I guess the good part about this situation is that this allowed the user to realize that they had this unwanted software installed... (In reply to Chris H-C :chutten from comment #0) > Anything we can do about this? The user's taking actions to scrub the unwanted third-party software... but could we have prevented it from causing such grief in Firefox? I think that this bug highlights a potential general performance issue in our `patched_LdrLoadDll` code, which we use to send notifications about DLL loads (begin, end). With our current code, if for some reason we end up *repeating failures to load the same DLL*, then we could be introducing a *lot* of overhead compared to standard `LdrLoadDll`, as we would be sending notifications for each failed attempt. To fix this issue, I think we should change how our `patched_LdrLoadDll` deals with failure. We need to find some compromise between what we want to be notified about, and the fact that loading may be failing over and over. For example, we could stop sending notifications for any library that reaches a fixed number of failures to load; and we could introduce a new event for when "a library somehow finally loaded successfully, but we didn't report the begin event because we assumed it would fail again and bring too much overhead". Here is how I think this general problem manifests in this specific bug. The recurring call stack that attempts to load the library in the profile you shared is: ``` kernelbase!LoadLibraryExW user32!_ClientLoadLibrary ntdll!KiUserCallbackDispatch win32u!NtUserPeekMessage user32!_PeekMessage user32!PeekMessageW ``` According to [this blogpost](https://opcode0x90.wordpress.com/2007/05/11/user32__clientloadlibraryx/), `_ClientLoadLibrary` is responsible for loading the DLL that contains a hook that was set through [SetWindowsHookExW](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowshookexw), before calling into that hook. So, here is what I think happened: - PremierOpinion set some hooks using `SetWindowsHookExW`, on at least one specific event which occurs a lot in the GPU process; - every time this event occurs and gets dispatched by `PeekMessageW` in the GPU process, an attempt to load `pmls64.dll` occurs; - because the DLL is not loaded, this calls into our `patched_LdrLoadDll`, and our notification code runs, introducing some overhead; - the DLL load fails (likely because of the GPU sandbox released with Firefox 110, see bug 1809519), so the DLL stays not loaded, meaning that with the next event we will go through `patched_LdrLoadDll` again. I'll try to reproduce the issue with my own hooks first.