Nightly runs are hitting R6034 dialog while loading C++ runtime library

[derekbruening]

From rnk@google.com on October 08, 2012 09:52:17

Attaching to common.eflags.exe with windbg on the bot didn't tell me anything useful:

0:000> k Child-SP RetAddr Call Site 000000000016e508 0000000073ac2dbf wow64cpu!CpupSyscallStub+0x9 000000000016e510 0000000073b3d07e wow64cpu!Thunk0Arg+0x5 000000000016e5d0 0000000073b3c549 wow64!RunCpuSimulation+0xa 000000000016e620 0000000077674956 wow64!Wow64LdrpInitialize+0x429 000000000016eb70 0000000077671a17 ntdll!LdrpInitializeProcess+0x17e4 000000000016f060 000000007765c32e ntdll! ?? ::FNODOBFM::string'+0x29220 000000000016f0d0 00000000`00000000 ntdll!LdrInitializeThunk+0xe http://build.chromium.org/p/client.drmemory/builders/win-7_x64-dr_nightly/builds/464/steps/Run%20DR%20nightly%20suite/logs/stdio It appears we eventually hit the 120 sec timeout and kill the process, so the bot makes progress, but much more slowly than it should.

Original issue: http://code.google.com/p/dynamorio/issues/detail?id=937

[derekbruening]

From rnk@google.com on October 11, 2012 07:04:57

Re-typing message box contents: R6034 An application has made an attempt to load the C runtime library incorrectly. Please contact the application's support team for more information.

I have a vague memory of this coming up on the chromium bots when we upgraded to VS2010 from VS2008? Does that ring any bells for anyone?

[derekbruening]

From rnk@google.com on October 11, 2012 07:07:06

Summary: Nightly runs are hitting R6034 dialog while loading C++ runtime library
Owner: rnk@google.com

[derekbruening]

From rnk@google.com on October 11, 2012 07:23:18

An actual stack trace:

0:000:x86> k ChildEBP RetAddr
00adefbc 760bcd46 USER32!NtUserWaitMessage+0x15 00adeff8 760bcf5c USER32!DialogBox2+0x222 00adf024 760ef73c USER32!InternalDialogBox+0xe5 00adf0d8 760efa18 USER32!SoftModalMessageBox+0x757 00adf230 760efb1f USER32!MessageBoxWorker+0x269 00adf29c 760efb9e USER32!MessageBoxTimeoutW+0x52 00adf2d0 760efcf1 USER32!MessageBoxTimeoutA+0x76 00adf2f0 760efd36 USER32!MessageBoxExA+0x1b 00adf30c 6e32d748 USER32!MessageBoxA+0x18 WARNING: Stack unwind information not available. Following frames may be wrong. 00adf344 6e2e2675 MSVCR90!rand_s+0x47e 00adf36c 6e2e2c30 MSVCR90!c_exit+0x1d6 00adf3a0 6e2e2d5e MSVCR90!_p__tzname+0xa6 00adf3b4 772e9950 MSVCR90!_p__tzname+0x1d4 00adf3d4 772ed8c9 ntdll_772b0000!RtlQueryEnvironmentVariable+0x241 00adf4c8 772ed78c ntdll_772b0000!LdrResSearchResource+0xb4d 00adf634 772ec4d5 ntdll_772b0000!LdrResSearchResource+0xa10 00adf66c 76822288 ntdll_772b0000!LdrLoadDll+0x7b 00adf6a8 768222e5 KERNELBASE!LoadLibraryExW+0x1f1 00adf6c8 763249d8 KERNELBASE!LoadLibraryExA+0x26 00adf6e8 00080007 KERNEL32!LoadLibraryA+0xba 00000000 00000000 0x80007

[derekbruening]

From rnk@google.com on October 11, 2012 08:36:00

Here we go. We have a _strnicmp import from msvcr(100|90).dll which I don't think we're supposed to have. I see this with dumpbin locally, but I don't get the message box:

$ dumpbin /dependents ./build_vmsafe-debug-internal-32/lib32/debug/dynamorio.dll ... ntdll.dll MSVCR100.dll

$ dumpbin /imports:msvcr100.dll ./build_vmsafe-debug-internal-32/lib32/debug/dynamorio.dll ... MSVCR100.dll ... 44B _strnicmp

We have only one use of _strnicmp in hotpatch.c, and that's only in the vmsafe/vps builds which is why we haven't seen it: https://code.google.com/p/dynamorio/source/search?q=strncasecmp&origq=strncasecmp&btnG=Search+Trunk I don't understand why we have this import. Shouldn't it be forwarded to ntdll through ntdll_imp?

[derekbruening]

From bruen...@google.com on October 11, 2012 09:11:44

we should add a dumpbin /dependents check as a post-build step to find these issues coming from the _alldvrm solution

is _strnicmp in the ntdll.lib used in builds where you can repro this? if not, add to ntdll_imports.def