B
Brent Scriver
We've identified a problem while compiling with Google Desktop
(5.8.0809.23506-en-pb) and Incredibuild (3.32) that can occur whenever
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs is
populated.
Google Desktop configures a DLL (GoogleDesktopNetwork3.dll) in the
AppInit_DLLs registry value under HKLM\Software\Microsoft\Windows
NT\CurrentVersion\Windows. This DLL apparently conflicts with something from
incredibuild so that if either one is not installed builds for Xbox work fine.
This appears to be a race condition between when the incredibuild dlls load
and when this dll gets unloaded causing the nondeterministic behavior.
To identify the issue I modified one of our internal debugging tools that
traps debug events from a running process so that it could automatically
start debugging whenever a target process starts (in this case cl.exe). From
there I could get the DLL list of what was actually loaded when running which
depends would not catch for this dll as it isn't a direct dependency.
Unfortunately my tool interferes with the race condition well enough to make
it much more likely to succeed building everything however it retrieved
enough information to perform further tests.
Some possible variants that could cause this are that the dlls initialized
this way are allocating memory in the range of the target PCH file or the dll
load conflicts with another dll causing it to be rebased into the region the
PCH is intended to load.
It might be worthwhile adding a check during compiles to identify this
scenario and report it (that the key is populated and what DLLs are in it)
when this error fires. A variant might be iterating through all modules
loaded into memory and finding out if the base to base + module size overlaps
the PCH region though it may not catch general memory allocations into that
memory region.
Even two dlls listed in that field that conflict could produce this issue as
well regardless of whether IB is installed.
Cheers!
-B
(5.8.0809.23506-en-pb) and Incredibuild (3.32) that can occur whenever
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs is
populated.
Google Desktop configures a DLL (GoogleDesktopNetwork3.dll) in the
AppInit_DLLs registry value under HKLM\Software\Microsoft\Windows
NT\CurrentVersion\Windows. This DLL apparently conflicts with something from
incredibuild so that if either one is not installed builds for Xbox work fine.
This appears to be a race condition between when the incredibuild dlls load
and when this dll gets unloaded causing the nondeterministic behavior.
To identify the issue I modified one of our internal debugging tools that
traps debug events from a running process so that it could automatically
start debugging whenever a target process starts (in this case cl.exe). From
there I could get the DLL list of what was actually loaded when running which
depends would not catch for this dll as it isn't a direct dependency.
Unfortunately my tool interferes with the race condition well enough to make
it much more likely to succeed building everything however it retrieved
enough information to perform further tests.
Some possible variants that could cause this are that the dlls initialized
this way are allocating memory in the range of the target PCH file or the dll
load conflicts with another dll causing it to be rebased into the region the
PCH is intended to load.
It might be worthwhile adding a check during compiles to identify this
scenario and report it (that the key is populated and what DLLs are in it)
when this error fires. A variant might be iterating through all modules
loaded into memory and finding out if the base to base + module size overlaps
the PCH region though it may not catch general memory allocations into that
memory region.
Even two dlls listed in that field that conflict could produce this issue as
well regardless of whether IB is installed.
Cheers!
-B