New issue
Advanced search Search tips

Issue 871847 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

verify that delay load depdenencies are actually being delay loaded by chrome.exe

Project Member Reported by wfh@chromium.org, Aug 7

Issue description

There have been reportedly times in the past when a DLL has been specified as delay load, but it's actually been pulled in by a dependency or some global constructor.

chrome.exe specifies a few delay load here:

https://cs.chromium.org/chromium/src/chrome/BUILD.gn?l=229

Currently:

dbghelp.dll
dwmapi.dll
uxtheme.dll
ole32.dll
oleaut32.dll

we should add tests or DCHECK to verify that these are always not loaded by the time chrome.exe wWinMain executes.

c.f. https://chromium-review.googlesource.com/c/chromium/src/+/1160797 and comments therein.
 
It would be even better for some of these delay loads to confirm that the DLLs in question are *never* loaded during normal browsing. i.e.; I think that dbghelp.dll and winhttp.dll are only supposed to be loaded if we crash or upload a crash. Checking at shutdown time that they aren't loaded would be nice although that is only a valid check under "normal" circumstances, so ???
I think it's hard to make strong guarantees beyond 'this is the expected state at process start' - because any DLL loaded in the future e.g. a Microsoft DLL, could have a delay load or a manual load of any other DLL e.g. winhttp.dll or dbghelp.dll
FWIW, manual inspection with procexp.exe shows that dbghelp.dll and the other four DLLs are all loaded into the browser process. Maybe that's fine, although I'm surprised that dbghelp.dll is loaded in.

FWIW.
yes, dbghelp.dll is pulled in by base...

specifically, the call(s) from base/debug/stack_trace_win.cc InitializeSymbols

https://cs.chromium.org/chromium/src/base/debug/stack_trace_win.cc?l=118
Summary: verify that delay load depdenencies are actually being delay loaded by chrome.exe (was: verify that delay load depdenencies are actually being delay loaded)
hmm ya this is from chrome.dll - it has a non-delay load dep on dbghelp.dll:

    dbghelp.dll
             18404A860 Import Address Table
             184048C20 Import Name Table
                     0 time date stamp
                     0 Index of first forwarder reference

                          2B StackWalk64
                          58 SymFromAddr
                          63 SymFunctionTableAccess64
                          6B SymGetLineFromAddr64
                          7D SymGetModuleBase64
                          88 SymGetSearchPathW
                          A2 SymInitialize
                          BE SymSetOptions
                          C4 SymSetSearchPathW


anyway, this bug is primarily about chrome.exe, but not chrome.dll - I think once MainDllLoader::Load is being called, we should pretty much be initialized... We could consider making dbghelp.dll delay load on chrome.dll?
Well that explains the browser process pulling it in. Delay load is probably worthwhile. Benefits are small, but non-zero.
Project Member

Comment 7 by bugdroid1@chromium.org, Aug 24

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/be4336650c4102d2580aa893b97d4ed996cb740a

commit be4336650c4102d2580aa893b97d4ed996cb740a
Author: Will Harris <wfh@chromium.org>
Date: Fri Aug 24 05:31:01 2018

Make dbghelp.dll a delay load DLL for chrome.dll.

Running Chrome normally and watching it for a few minutes, I don't
see this being delay loaded by anything, so this is probably
a load time improvement.

BUG=871847

Change-Id: I7c6647325f63d7d7dfa0e6b0807c15757cf8fda0
Reviewed-on: https://chromium-review.googlesource.com/1187711
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Commit-Queue: Will Harris <wfh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#585702}
[modify] https://crrev.com/be4336650c4102d2580aa893b97d4ed996cb740a/chrome/BUILD.gn

Sign in to add a comment