Issue metadata
Sign in to add a comment
|
Chrome is crashing if UserDataDir contains variable ${client_name}
Reported by
lahm...@gmail.com,
Jul 26 2017
|
||||||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0
Steps to reproduce the problem:
1. Install Chrome Bundle x64 GoogleChromeStandaloneEnterprise64.msi, OS: Windows Server 2008 R2 (RDS Windows Remote Desktop environment)
2. Set chrome policy "Set user data directory" to "${local_app_data}\Google\Chrome\UserData${client_name}"
3. Start chrome.exe
What is the expected behavior?
Chrome starts
What went wrong?
Chrome immediately crashes after starting chrome.exe.
==> "Google Chrome has stopped working" +
==> "The application was unable to start correctly (0xc0000005)"
Crashed report ID:
How much crashed? Whole browser
Is it a problem with a plugin? No
Did this work before? Yes 59.0.3071.115
Chrome version: <Copy from: 60.0.3112.78 Channel: stable
OS Version: 2008 R2 (RDS-Session)
Flash Version:
I believe it is the same issue as reported under https://bugs.chromium.org/p/chromium/issues/detail?id=700371
,
Jul 26 2017
,
Jul 26 2017
This doesn't reproduce without citrix, afaict, so I think it's something specific to that environment or client_name https://cs.chromium.org/chromium/src/chrome/install_static/policy_path_parser.cc?rcl=aa061e550891fab4b55e75d85955e27eed25bf94&l=140 and presumably server_name. I confirmed that the CL from 700371 hasn't been reintroduced, and that other variables like ${user_name} work as expected. e.g. "${local_app_data}\Google\Chrome\UserData${user_name}" seemed to work ok. Maybe the lookup of WTSQuerySessionInformationW is just failing and we're calling nullptr? Would need to get a repro or a crash report, but I guess this happens too early to get a crash report on the server.
,
Jul 26 2017
,
Jul 26 2017
Think this is caused by few other issues with Chrome on Citrix 6.5. Please check https://bugs.chromium.org/p/chromium/issues/detail?id=432595#c15 and try if this workaround helps. Chrome works fine using Citrix 7.0/ Win2012 server. Please provide your environment details and crash id from chrome://crashes for detailed investigation.
,
Jul 27 2017
This is reproducible on reported Chrome#60.0.3112.78 on my corp Win7 without any citrix server and working fine on previous stable#59.0.3071.115.
,
Jul 27 2017
I do not see any crash related info, however i'm attaching 'UserDir' info if someone wants to take a look. https://goto.google.com/irkyk Thank you!
,
Jul 27 2017
,
Jul 27 2017
Hello can you please share if setting UserDataDir to only "${local_app_data}\Google\Chrome\UserData" works for you? If so does ${session_name} work in place of the ${client_name}?
,
Jul 27 2017
Hello,
"${local_app_data}\Google\Chrome\UserData" works for me
"${local_app_data}\Google\Chrome\UserData${session_name}" does not work
,
Jul 27 2017
@scottmg: This seems to be a regression in Chrome 60 with calling various Windows APIs from inside the chrome_elf!install_static::ExpandPathVariables function. You can reproduce this issue on a Win 7 box with local policy set on that machine. I first reproed the issue on a Windows Server 2008 R2 machine and don't even need to be in a remote session simply starting chrome when the UserDataDir policy s set accordingly is enough to reproduce the issue. Here is the dump of running !analyze -v on the chrome process in WinDbg 0:000:x86> !analyze -v ******************************************************************************* * * * Exception Analysis * * * ******************************************************************************* GetUrlPageData2 (WinHttp) failed: 12002. DUMP_CLASS: 2 DUMP_QUALIFIER: 0 FAULTING_IP: ntdll32!RtlpWaitOnCriticalSection+bd 7724eb83 ff4014 inc dword ptr [eax+14h] EXCEPTION_RECORD: (.exr -1) ExceptionAddress: 7724eb83 (ntdll32!RtlpWaitOnCriticalSection+0x000000bd) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 00000001 Parameter[1]: 00000014 Attempt to write to address 00000014 FAULTING_THREAD: 0000010c DEFAULT_BUCKET_ID: NULL_CLASS_PTR_WRITE PROCESS_NAME: chrome.exe ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_CODE_STR: c0000005 EXCEPTION_PARAMETER1: 00000001 EXCEPTION_PARAMETER2: 00000014 FOLLOWUP_IP: ntdll32!RtlpWaitOnCriticalSection+bd 7724eb83 ff4014 inc dword ptr [eax+14h] WRITE_ADDRESS: 00000014 WATSON_BKT_PROCSTAMP: 5976ae77 WATSON_BKT_PROCVER: 60.0.3112.78 PROCESS_VER_PRODUCT: Google Chrome WATSON_BKT_MODULE: ntdll32.dll WATSON_BKT_MODSTAMP: 58bf8715 WATSON_BKT_MODOFFSET: 4eb83 WATSON_BKT_MODVER: 6.1.7601.23714 MODULE_VER_PRODUCT: Microsoft® Windows® Operating System BUILD_VERSION_STRING: 7601.23714.amd64fre.win7sp1_ldr.170307-1800 MODLIST_WITH_TSCHKSUM_HASH: 04737e8814addd0aa46775cd5637e9e8c9efa032 MODLIST_SHA1_HASH: 3ad612c50b7ee69edf9400abfdbf1873a8e25088 APPLICATION_VERIFIER_FLAGS: 0 PRODUCT_TYPE: 3 SUITE_MASK: 16 DUMP_TYPE: fe ANALYSIS_SESSION_HOST: XENAPP ANALYSIS_SESSION_TIME: 07-27-2017 01:46:41.0144 ANALYSIS_VERSION: 10.0.15063.137 amd64fre THREAD_ATTRIBUTES: OS_LOCALE: ENU PROBLEM_CLASSES: ID: [0n292] Type: [@ACCESS_VIOLATION] Class: Addendum Scope: BUCKET_ID Name: Omit Data: Omit PID: [Unspecified] TID: [0x10c] Frame: [0] : ntdll32!RtlpWaitOnCriticalSection ID: [0n265] Type: [INVALID_POINTER_WRITE] Class: Primary Scope: BUCKET_ID Name: Add Data: Omit PID: [Unspecified] TID: [0x10c] Frame: [0] : ntdll32!RtlpWaitOnCriticalSection ID: [0n290] Type: [NULL_CLASS_PTR_WRITE] Class: Primary Scope: DEFAULT_BUCKET_ID (Failure Bucket ID prefix) BUCKET_ID Name: Add Data: Omit PID: [0x1c1c] TID: [0x10c] Frame: [0] : ntdll32!RtlpWaitOnCriticalSection ID: [0n152] Type: [ZEROED_STACK] Class: Addendum Scope: BUCKET_ID Name: Add Data: Omit PID: [0x1c1c] TID: [0x10c] Frame: [0] : ntdll32!RtlpWaitOnCriticalSection BUGCHECK_STR: APPLICATION_FAULT_NULL_CLASS_PTR_WRITE_INVALID_POINTER_WRITE PRIMARY_PROBLEM_CLASS: APPLICATION_FAULT LAST_CONTROL_TRANSFER: from 7724ea92 to 7724eb83 STACK_TEXT: 001ee6a4 7724ea92 00000000 00000000 00000000 ntdll32!RtlpWaitOnCriticalSection+0xbd 001ee6cc 76a5f71b 76b00a54 00000008 0000330c ntdll32!RtlEnterCriticalSection+0x150 001ee704 76a91610 762c45c8 001ee738 762d0e37 RPCRT4!PerformRpcInitialization+0x22 001ee710 762d0e37 00000000 762c15ac 00000000 RPCRT4!RpcStringBindingComposeW+0x14 001ee738 76a5aef3 00000000 00000001 001eebb0 sechost!PLSA_LOOKPR_SERVER_NAME_bind+0x2e 001ee75c 76a5af21 00000000 00000008 001ee8e0 RPCRT4!GenericHandleMgr+0xd2 001ee774 76af01fe 762c45e8 001ee8e0 dd805885 RPCRT4!ExplicitBindHandleMgr+0x44 001eeb90 762d0d20 762c45e8 762c3f22 001eebb0 RPCRT4!NdrClientCall2+0x119 001eeba8 762d0699 00000000 001eec0c 00000800 sechost!LsaLookuprOpenPolicy2+0x19 001eebf4 762d02f9 001eec0c 00000800 001eec38 sechost!LsaLookupOpenLocalPolicy+0x2d 001eec4c 762d0630 00459cf0 00661278 001eece4 sechost!LookupAccountSidInternal+0x4c 001eec70 766147f4 00459cf0 00661278 001eece4 sechost!LookupAccountSidLocalW+0x1e 001eec90 6f9b7948 00000000 00459cf0 00661278 ADVAPI32!LookupAccountSidW+0x46 001eed0c 6f9b7836 00459cf0 6f9d5a08 001eef6c WINSTA!CUtils::GetNameFromSid+0xa9 001eed30 6f9b77d0 6f9b5d40 6f9b5c9c 6f9b3b98 WINSTA!CPublicBinding::CreateLocalSPNs+0x63 001eed38 6f9b5c9c 6f9b3b98 00000000 001ef000 WINSTA!CPublicBinding::GetLSMBinding+0x1e 001eeedc 6f9b3b7c 00000000 00000001 00000008 WINSTA!Public_WinStationQueryInformationW+0x9e 001eef08 747e25d7 00000000 ffffffff 00000008 WINSTA!WinStationQueryInformationW+0x10f 001eefc4 6d75a339 00000000 ffffffff 00000006 wtsapi32!WTSQuerySessionInformationW+0xa2 001ef250 6d759a35 6d7adf00 001ef624 001ef60c chrome_elf!install_static::ExpandPathVariables+0x47f 001ef2c8 6d759ba9 001ef60c 001ef624 6d7adf00 chrome_elf!install_static::`anonymous namespace'::GetUserDataDirFromRegistryPolicyIfSet+0xa5 001ef520 6d759d2c 001ef60c 001ef624 001ef650 chrome_elf!install_static::DeriveUserDataDirectoryImpl+0x37 001ef58c 6d75637e 001ef624 00000007 00000000 chrome_elf!install_static::DeriveUserDataDirectory+0x51 001ef640 6d755eea 00000001 00000001 002923c8 chrome_elf!install_static::MakeProductDetails+0x23c 001ef688 6d751127 dd80457d 00000001 00000001 chrome_elf!install_static::InitializeProductDetailsForPrimaryModule+0xa7 001ef6bc 6d77c37a 6d750000 00000001 001efa18 chrome_elf!DllMain+0x17 001ef6fc 6d77c44c 6d750000 00000001 001efa18 chrome_elf!dllmain_dispatch+0x70 001ef710 77239364 6d750000 00000001 001efa18 chrome_elf!_DllMainCRTStartup+0x1c 001ef730 7723fe21 6d77c430 6d750000 00000001 ntdll32!LdrpCallInitRoutine+0x14 001ef824 7724b3f8 001efa18 fffdd000 fffde000 ntdll32!LdrpRunInitializeRoutines+0x26f 001ef9a4 77249eb5 001efa18 77200000 7717571c ntdll32!LdrpInitializeProcess+0x1402 001ef9f4 77239889 001efa18 77200000 00000000 ntdll32!_LdrpInitialize+0x78 001efa04 00000000 001efa18 77200000 00000000 ntdll32!LdrInitializeThunk+0x10 THREAD_SHA1_HASH_MOD_FUNC: 42ef5be445a1e18261bd6b2e8d24353d3441e6aa THREAD_SHA1_HASH_MOD_FUNC_OFFSET: 32c0eaa8268c429162311e9399f37e57e274798c THREAD_SHA1_HASH_MOD: 3ee7edd8cd223ed9d5bb30eca6494a1ee3291915 FAULT_INSTR_CODE: 8b1440ff SYMBOL_STACK_INDEX: 0 SYMBOL_NAME: ntdll32!RtlpWaitOnCriticalSection+bd FOLLOWUP_NAME: MachineOwner MODULE_NAME: ntdll32 IMAGE_NAME: ntdll32.dll DEBUG_FLR_IMAGE_TIMESTAMP: 58bf8715 STACK_COMMAND: ~0s ; kb FAILURE_BUCKET_ID: NULL_CLASS_PTR_WRITE_c0000005_ntdll32.dll!RtlpWaitOnCriticalSection BUCKET_ID: X64_APPLICATION_FAULT_NULL_CLASS_PTR_WRITE_INVALID_POINTER_WRITE_ntdll32!RtlpWaitOnCriticalSection+bd FAILURE_EXCEPTION_CODE: c0000005 FAILURE_IMAGE_NAME: ntdll32.dll BUCKET_ID_IMAGE_STR: ntdll32.dll FAILURE_MODULE_NAME: ntdll32 BUCKET_ID_MODULE_STR: ntdll32 FAILURE_FUNCTION_NAME: RtlpWaitOnCriticalSection BUCKET_ID_FUNCTION_STR: RtlpWaitOnCriticalSection BUCKET_ID_OFFSET: bd BUCKET_ID_MODTIMEDATESTAMP: 58bf8715 BUCKET_ID_MODCHECKSUM: 14e37e BUCKET_ID_MODVER_STR: 6.1.7601.23714 BUCKET_ID_PREFIX_STR: X64_APPLICATION_FAULT_NULL_CLASS_PTR_WRITE_INVALID_POINTER_WRITE_ FAILURE_PROBLEM_CLASS: APPLICATION_FAULT FAILURE_SYMBOL_NAME: ntdll32.dll!RtlpWaitOnCriticalSection WATSON_STAGEONE_URL: http://watson.microsoft.com/StageOne/chrome.exe/60.0.3112.78/5976ae77/ntdll32.dll/6.1.7601.23714/58bf8715/c0000005/0004eb83.htm?Retriage=1 TARGET_TIME: 2017-07-27T08:46:44.000Z OSBUILD: 7601 OSSERVICEPACK: 1 SERVICEPACK_NUMBER: 0 OS_REVISION: 0 OSPLATFORM_TYPE: x64 OSNAME: Windows 7 OSEDITION: Windows 7 Server (Service Pack 1) TerminalServer USER_LCID: 0 OSBUILD_TIMESTAMP: 2017-03-07 20:25:30 BUILDDATESTAMP_STR: 170307-1800 BUILDLAB_STR: win7sp1_ldr BUILDOSVER_STR: 6.1.7601.23714.amd64fre.win7sp1_ldr.170307-1800 ANALYSIS_SESSION_ELAPSED_TIME: 6054 ANALYSIS_SOURCE: UM FAILURE_ID_HASH_STRING: um:null_class_ptr_write_c0000005_ntdll32.dll!rtlpwaitoncriticalsection FAILURE_ID_HASH: {9db511b1-73db-3c0c-0b9e-73237faabe2a} Followup: MachineOwner --------- Next I tried a few more things and the scope of the issue is actually Win 7 based OSes both 32 and 64 bit version of Chrome is affected. Also the ${user_name} variable is crashing the same way which uses different API Here is the stack trace from that experiment: STACK_TEXT: 0045ea8c 7724ea92 00000000 00000000 00000000 ntdll32!RtlpWaitOnCriticalSection+0xbd 0045eab4 76a5f71b 76b00a54 00000000 007863fd ntdll32!RtlEnterCriticalSection+0x150 0045eaec 76a91610 00001a5c 0045eb24 74ab9f21 RPCRT4!PerformRpcInitialization+0x22 0045eaf8 74ab9f21 00000000 74ab0c14 00000000 RPCRT4!RpcStringBindingComposeW+0x14 0045eb24 74ab4c8f 0045eb48 33da3f15 00000000 SspiCli!SecpGetRpcBinding+0x2d 0045eb64 74ab9b74 00000000 00000002 0045eb9c SspiCli!CreateRpcConnection+0x19 0045ebb8 74ab9d1b 0045ec8c 0045eccc 00000000 SspiCli!InitState+0x55 0045ebd0 74ab9d6b 0045ebdc 00000000 0045ec54 SspiCli!IsOkayToExec+0x96 0045ebe0 74ab5fce 0045ec38 33da3825 00000000 SspiCli!IsOkayToExecRpc+0xf 0045ec54 74aba442 00010002 0045ec74 0045ec8c SspiCli!SspipGetUserName+0x38 0045ec7c 766114d7 00010002 00000000 00000000 SspiCli!GetUserNameExW+0x33 0045ec90 679ea0df 00000000 0045eccc 00000001 ADVAPI32!GetUserNameW+0x15 0045ef10 679e9a35 67a3df00 0045f2e4 0045f2cc chrome_elf!install_static::ExpandPathVariables+0x225 0045ef88 679e9ba9 0045f2cc 0045f2e4 67a3df00 chrome_elf!install_static::`anonymous namespace'::GetUserDataDirFromRegistryPolicyIfSet+0xa5 0045f1e0 679e9d2c 0045f2cc 0045f2e4 0045f310 chrome_elf!install_static::DeriveUserDataDirectoryImpl+0x37 0045f24c 679e637e 0045f2e4 00000007 00000000 chrome_elf!install_static::DeriveUserDataDirectory+0x51 0045f300 679e5eea 00000001 00000001 002723c8 chrome_elf!install_static::MakeProductDetails+0x23c 0045f348 679e1127 33da2734 00000001 00000001 chrome_elf!install_static::InitializeProductDetailsForPrimaryModule+0xa7 0045f37c 67a0c37a 679e0000 00000001 0045f6d8 chrome_elf!DllMain+0x17 0045f3bc 67a0c44c 679e0000 00000001 0045f6d8 chrome_elf!dllmain_dispatch+0x70 0045f3d0 77239364 679e0000 00000001 0045f6d8 chrome_elf!_DllMainCRTStartup+0x1c 0045f3f0 7723fe21 67a0c430 679e0000 00000001 ntdll32!LdrpCallInitRoutine+0x14 0045f4e4 7724b3f8 0045f6d8 fffdd000 fffde000 ntdll32!LdrpRunInitializeRoutines+0x26f 0045f664 77249eb5 0045f6d8 77200000 771f44c9 ntdll32!LdrpInitializeProcess+0x1402 0045f6b4 77239889 0045f6d8 77200000 00000000 ntdll32!_LdrpInitialize+0x78 0045f6c4 00000000 0045f6d8 77200000 00000000 ntdll32!LdrInitializeThunk+0x10
,
Jul 27 2017
Able to reproduce this issue on Windows 7(GPO - Skytap environment) with chrome #60.0.3112.78 as per steps mentioned in the comment #0. Observed error "The application was unable to start correctly (0xc0000005)". Note: Issue is not observed on Windows 10.
,
Jul 27 2017
Oh dear, yeah, that's getting called too early. :( I think due to https://codereview.chromium.org/2867063002/ which landed in 60. https://storage.googleapis.com/chromium-find-releases-static/fec.html#fecdf607e706474b65a4d26e554f0504aead3f3e I don't know how revertable it is, but it's definitely not a small CL. :(
,
Jul 27 2017
I initially tried to repro on my Win10 dev machine... But I forgot that the AppCompat that Microsoft shims us with on Win10 means that all the DLLs are already loaded so chrome_elf is loaded almost-last, so it happens to work there. So this only happens on Win7 (and Server 2008) I believe.
,
Jul 27 2017
Surprisingly enough, that CL is revertable at head with only one trivial conflict in chrome/install_static/install_util.cc. https://chromium-review.googlesource.com/c/589775/ Despite it being a large change, that would be my preferred solution to un-crash Stable unless someone knows if there's a logical conflict caused by doing so.
,
Jul 27 2017
Off the top of my head, I don't think there's a logical conflict with reverting.
,
Jul 27 2017
For context, the motivation behind adding the user data dir to install details is that, just like previous install details, it should be computed only once and then reused. InstallDetails provided the mechanism to do this.
,
Jul 27 2017
Yup, totally makes sense, unfortunately it has to happen after DllMain of chrome_elf, because variable expansion in UserDataDir causes dll loads, which fail because chrome_elf has the loader lock. :( I thought we had at least a manual test after the first time I shipped this in 54, but now we've managed to ship basically the same bug for the third time! I feel like an moron. We'll have to move that code out of install_static, and make it not LoadLibrary() so that this is hard to do by accident.
,
Jul 27 2017
Is there any reason why we couldn't pass the browser's input flags (like --user-data-dir if any) on to the handler, and then compute the user data dir & crash dir in the handler process?
,
Jul 27 2017
I think grt's concern was that might lead to inconsistent user-data-dirs if something changed between computations.
,
Jul 27 2017
Issue 749682 has been merged into this issue.
,
Jul 27 2017
When I see the same thing happening (more-or-less) in multiple code locations, I figure it's just a matter of time before the code gets out of sync. It's oh-so-easy to fix a bug *here* and forget that the same bug exists over *there*. That's my biggest concern. The smaller one is what happens if the sands shift at runtime somehow so that the two code locations end up with different results. If you're okay with carrying the burden of those two, I am.
,
Jul 28 2017
So the problem here would have to be that all of chrome.exe's import dependencies have been loaded, and presumably bound, but not initialized. We're in the initialization of the first of chrome.exe's dependencies - chrome_elf, so at this time only its dependencies have been initialized. This means that the ADVAPI32!GetUserNameW call ends up calling into the non-initialized RPCRT4. It's likely that ADVAPI32 is also non-initialized, but that this API doesn't require any initialization (or that it malfunctions without crashing). If we can't reliably compute the profile directory without invoking into ADVAPI and/or directly or indirectly into other import dependencies of chrome.exe, then we simply can't reliably compute the profile directory until chrome!main. More specifically, we can't compute the profile directory until the loader's lock has been released after initial loading - so it's for example fine to do this in a thread that's spawned from chrome_elf!DllMain. This is going to be a problem for e.g. the upcoming third-party policy work - Chris?
,
Jul 28 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/332af9ce8cf255ba7dc1604ab4a56e1c597ed338 commit 332af9ce8cf255ba7dc1604ab4a56e1c597ed338 Author: Scott Graham <scottmg@chromium.org> Date: Fri Jul 28 15:49:51 2017 Revert "Stability instrumentation Crashpad integration" This reverts commit fecdf607e706474b65a4d26e554f0504aead3f3e. Suspected of causing crashes on Win7 Stable 60 when UserDataDir is set to have expandable ${variables} in it. :( This will need to be back merged to 60 and 61. Bug: 718437 , 748949 Cq-Include-Trybots: master.tryserver.chromium.win:win10_chromium_x64_rel_ng Change-Id: Id379a7c167f536154af1c67aa3dc6e17ca516934 Reviewed-on: https://chromium-review.googlesource.com/589775 Reviewed-by: Greg Thompson <grt@chromium.org> Reviewed-by: Mark Mentovai <mark@chromium.org> Reviewed-by: Robert Shield <robertshield@chromium.org> Reviewed-by: Sigurður Ásgeirsson <siggi@chromium.org> Reviewed-by: Alex Clarke <alexclarke@chromium.org> Commit-Queue: Scott Graham <scottmg@chromium.org> Cr-Commit-Position: refs/heads/master@{#490410} [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/chrome/app/chrome_crash_reporter_client_win.cc [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/chrome/app/chrome_exe_main_win.cc [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/chrome/app/chrome_main_delegate.cc [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/chrome/chrome_watcher/chrome_watcher_main.cc [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/chrome/install_static/install_details.cc [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/chrome/install_static/install_details.h [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/chrome/install_static/install_util.cc [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/chrome/install_static/install_util.h [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/chrome/install_static/install_util_unittest.cc [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/chrome/install_static/product_install_details.cc [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/chrome/install_static/user_data_dir.cc [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/chrome/install_static/user_data_dir.h [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/chrome/install_static/user_data_dir_win_unittest.cc [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/chrome/installer/setup/installer_crash_reporting.cc [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/chrome/installer/setup/setup_main.cc [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/chrome_elf/chrome_elf.def [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/chrome_elf/chrome_elf_main.cc [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/components/browser_watcher/BUILD.gn [delete] https://crrev.com/e0db29894d5e4cbdeafc786d3ab0b4205083d419/components/browser_watcher/minidump_user_streams.h [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/components/browser_watcher/postmortem_minidump_writer_win.cc [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/components/browser_watcher/stability_report_extractor.cc [delete] https://crrev.com/e0db29894d5e4cbdeafc786d3ab0b4205083d419/components/browser_watcher/stability_report_user_stream_data_source.cc [delete] https://crrev.com/e0db29894d5e4cbdeafc786d3ab0b4205083d419/components/browser_watcher/stability_report_user_stream_data_source.h [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/components/crash/content/app/BUILD.gn [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/components/crash/content/app/DEPS [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/components/crash/content/app/crashpad.cc [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/components/crash/content/app/crashpad.h [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/components/crash/content/app/crashpad_mac.mm [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/components/crash/content/app/crashpad_win.cc [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/components/crash/content/app/run_as_crashpad_handler_win.cc [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/components/crash/content/app/run_as_crashpad_handler_win.h [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/headless/app/headless_shell.cc [modify] https://crrev.com/332af9ce8cf255ba7dc1604ab4a56e1c597ed338/headless/lib/headless_content_main_delegate.cc
,
Jul 28 2017
Since we can't know the user data dir at the time when we'd like to initialize crash reporting, in order to allow early Crashpad initialization, the StartHandler method needs to be split in two. The first part would set up the pipe and handles that are inherited into the handler process. The second part takes the user data dir and other parameters that the handler needs, and creates the process. Alternatively the StartHandler method could take an interface or a callback that produces the information needed only as the process is being created.
,
Jul 31 2017
More reports in the wild: https://groups.google.com/a/chromium.org/forum/#!topic/chromium-discuss/TT83c50lWXk
,
Jul 31 2017
For 332af9ce8cf255ba7dc1604ab4a56e1c597ed338 landed in 62.0.3170.0.
,
Jul 31 2017
This bug requires manual review: DEPS changes referenced in bugdroid comments. Please contact the milestone owner if you have questions. Owners: amineer@(Android), cmasso@(iOS), ketakid @(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 31 2017
This bug requires manual review: Request affecting a post-stable build Please contact the milestone owner if you have questions. Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 31 2017
Before we approve merge to M61, could you please confirm change listed at #24 is well baked/verified in Canary, having enough automation tests coverage and will be safe merge to M61?
,
Jul 31 2017
I do not see this issue anymore after the above revert (c#24) on Latest Canary#62.0.3172.2 for Win 7 (64-bit).
,
Jul 31 2017
The change in #24 meets the bar and is approved for merge into M60
,
Jul 31 2017
Re: #c30, it's a revert, so I think by definition we don't have enough automated test coverage. :( But it's been in Canary since Friday and appears to fix the regression per #c31.
,
Jul 31 2017
Thank you scottmg@. Sorry my bad, missed that it is a revert. Approving merge to M61 branch #3163 based on comment #31, #32 & #33. Please
,
Jul 31 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/47b9c67f3a9afdb490ae69900c7cac262688b996 commit 47b9c67f3a9afdb490ae69900c7cac262688b996 Author: Scott Graham <scottmg@chromium.org> Date: Mon Jul 31 23:15:42 2017 Revert "Stability instrumentation Crashpad integration" This reverts commit fecdf607e706474b65a4d26e554f0504aead3f3e. Suspected of causing crashes on Win7 Stable 60 when UserDataDir is set to have expandable ${variables} in it. :( This will need to be back merged to 60 and 61. TBR=scottmg@chromium.org (cherry picked from commit 332af9ce8cf255ba7dc1604ab4a56e1c597ed338) Bug: 718437 , 748949 Cq-Include-Trybots: master.tryserver.chromium.win:win10_chromium_x64_rel_ng Change-Id: Id379a7c167f536154af1c67aa3dc6e17ca516934 Reviewed-on: https://chromium-review.googlesource.com/589775 Reviewed-by: Greg Thompson <grt@chromium.org> Reviewed-by: Mark Mentovai <mark@chromium.org> Reviewed-by: Robert Shield <robertshield@chromium.org> Reviewed-by: Sigurður Ásgeirsson <siggi@chromium.org> Reviewed-by: Alex Clarke <alexclarke@chromium.org> Commit-Queue: Scott Graham <scottmg@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#490410} Reviewed-on: https://chromium-review.googlesource.com/595142 Reviewed-by: Scott Graham <scottmg@chromium.org> Cr-Commit-Position: refs/branch-heads/3163@{#197} Cr-Branched-From: ff259bab28b35d242e10186cd63af7ed404fae0d-refs/heads/master@{#488528} [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/chrome/app/chrome_crash_reporter_client_win.cc [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/chrome/app/chrome_exe_main_win.cc [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/chrome/app/chrome_main_delegate.cc [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/chrome/chrome_watcher/chrome_watcher_main.cc [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/chrome/install_static/install_details.cc [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/chrome/install_static/install_details.h [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/chrome/install_static/install_util.cc [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/chrome/install_static/install_util.h [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/chrome/install_static/install_util_unittest.cc [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/chrome/install_static/product_install_details.cc [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/chrome/install_static/user_data_dir.cc [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/chrome/install_static/user_data_dir.h [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/chrome/install_static/user_data_dir_win_unittest.cc [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/chrome/installer/setup/installer_crash_reporting.cc [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/chrome/installer/setup/setup_main.cc [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/chrome_elf/chrome_elf.def [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/chrome_elf/chrome_elf_main.cc [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/components/browser_watcher/BUILD.gn [delete] https://crrev.com/0efea6c59691b7a81801445595eb7f84b2da951a/components/browser_watcher/minidump_user_streams.h [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/components/browser_watcher/postmortem_minidump_writer_win.cc [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/components/browser_watcher/stability_report_extractor.cc [delete] https://crrev.com/0efea6c59691b7a81801445595eb7f84b2da951a/components/browser_watcher/stability_report_user_stream_data_source.cc [delete] https://crrev.com/0efea6c59691b7a81801445595eb7f84b2da951a/components/browser_watcher/stability_report_user_stream_data_source.h [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/components/crash/content/app/BUILD.gn [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/components/crash/content/app/DEPS [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/components/crash/content/app/crashpad.cc [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/components/crash/content/app/crashpad.h [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/components/crash/content/app/crashpad_mac.mm [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/components/crash/content/app/crashpad_win.cc [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/components/crash/content/app/run_as_crashpad_handler_win.cc [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/components/crash/content/app/run_as_crashpad_handler_win.h [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/headless/app/headless_shell.cc [modify] https://crrev.com/47b9c67f3a9afdb490ae69900c7cac262688b996/headless/lib/headless_content_main_delegate.cc
,
Jul 31 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/44e7e44ccad3609ca8acfccfa88768488bb25463 commit 44e7e44ccad3609ca8acfccfa88768488bb25463 Author: Scott Graham <scottmg@chromium.org> Date: Mon Jul 31 23:53:02 2017 Revert "Stability instrumentation Crashpad integration" This reverts commit fecdf607e706474b65a4d26e554f0504aead3f3e. Suspected of causing crashes on Win7 Stable 60 when UserDataDir is set to have expandable ${variables} in it. :( This will need to be back merged to 60 and 61. TBR=scottmg@chromium.org (cherry picked from commit 332af9ce8cf255ba7dc1604ab4a56e1c597ed338) Bug: 718437 , 748949 Cq-Include-Trybots: master.tryserver.chromium.win:win10_chromium_x64_rel_ng Change-Id: Id379a7c167f536154af1c67aa3dc6e17ca516934 Reviewed-on: https://chromium-review.googlesource.com/589775 Reviewed-by: Greg Thompson <grt@chromium.org> Reviewed-by: Mark Mentovai <mark@chromium.org> Reviewed-by: Robert Shield <robertshield@chromium.org> Reviewed-by: Sigurður Ásgeirsson <siggi@chromium.org> Reviewed-by: Alex Clarke <alexclarke@chromium.org> Commit-Queue: Scott Graham <scottmg@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#490410} Reviewed-on: https://chromium-review.googlesource.com/595145 Reviewed-by: Scott Graham <scottmg@chromium.org> Cr-Commit-Position: refs/branch-heads/3112@{#698} Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897} [modify] https://crrev.com/44e7e44ccad3609ca8acfccfa88768488bb25463/chrome/app/chrome_crash_reporter_client_win.cc [modify] https://crrev.com/44e7e44ccad3609ca8acfccfa88768488bb25463/chrome/app/chrome_exe_main_win.cc [modify] https://crrev.com/44e7e44ccad3609ca8acfccfa88768488bb25463/chrome/app/chrome_main_delegate.cc [modify] https://crrev.com/44e7e44ccad3609ca8acfccfa88768488bb25463/chrome/install_static/install_details.cc [modify] https://crrev.com/44e7e44ccad3609ca8acfccfa88768488bb25463/chrome/install_static/install_details.h [modify] https://crrev.com/44e7e44ccad3609ca8acfccfa88768488bb25463/chrome/install_static/install_util.cc [modify] https://crrev.com/44e7e44ccad3609ca8acfccfa88768488bb25463/chrome/install_static/install_util.h [modify] https://crrev.com/44e7e44ccad3609ca8acfccfa88768488bb25463/chrome/install_static/install_util_unittest.cc [modify] https://crrev.com/44e7e44ccad3609ca8acfccfa88768488bb25463/chrome/install_static/product_install_details.cc [modify] https://crrev.com/44e7e44ccad3609ca8acfccfa88768488bb25463/chrome/install_static/user_data_dir.cc [modify] https://crrev.com/44e7e44ccad3609ca8acfccfa88768488bb25463/chrome/install_static/user_data_dir.h [modify] https://crrev.com/44e7e44ccad3609ca8acfccfa88768488bb25463/chrome/install_static/user_data_dir_win_unittest.cc [modify] https://crrev.com/44e7e44ccad3609ca8acfccfa88768488bb25463/chrome/installer/setup/installer_crash_reporting.cc [modify] https://crrev.com/44e7e44ccad3609ca8acfccfa88768488bb25463/chrome/installer/setup/setup_main.cc [modify] https://crrev.com/44e7e44ccad3609ca8acfccfa88768488bb25463/chrome_elf/chrome_elf.def [modify] https://crrev.com/44e7e44ccad3609ca8acfccfa88768488bb25463/chrome_elf/chrome_elf_main.cc [modify] https://crrev.com/44e7e44ccad3609ca8acfccfa88768488bb25463/components/browser_watcher/BUILD.gn [delete] https://crrev.com/d929afacff82766b8dd0ee27d2ccd8a3e297c805/components/browser_watcher/minidump_user_streams.h [modify] https://crrev.com/44e7e44ccad3609ca8acfccfa88768488bb25463/components/browser_watcher/postmortem_minidump_writer_win.cc [modify] https://crrev.com/44e7e44ccad3609ca8acfccfa88768488bb25463/components/browser_watcher/stability_report_extractor.cc [delete] https://crrev.com/d929afacff82766b8dd0ee27d2ccd8a3e297c805/components/browser_watcher/stability_report_user_stream_data_source.cc [delete] https://crrev.com/d929afacff82766b8dd0ee27d2ccd8a3e297c805/components/browser_watcher/stability_report_user_stream_data_source.h [modify] https://crrev.com/44e7e44ccad3609ca8acfccfa88768488bb25463/components/crash/content/app/BUILD.gn [modify] https://crrev.com/44e7e44ccad3609ca8acfccfa88768488bb25463/components/crash/content/app/DEPS [modify] https://crrev.com/44e7e44ccad3609ca8acfccfa88768488bb25463/components/crash/content/app/crashpad.cc [modify] https://crrev.com/44e7e44ccad3609ca8acfccfa88768488bb25463/components/crash/content/app/crashpad.h [modify] https://crrev.com/44e7e44ccad3609ca8acfccfa88768488bb25463/components/crash/content/app/crashpad_mac.mm [modify] https://crrev.com/44e7e44ccad3609ca8acfccfa88768488bb25463/components/crash/content/app/crashpad_win.cc [modify] https://crrev.com/44e7e44ccad3609ca8acfccfa88768488bb25463/components/crash/content/app/run_as_crashpad_handler_win.cc [modify] https://crrev.com/44e7e44ccad3609ca8acfccfa88768488bb25463/components/crash/content/app/run_as_crashpad_handler_win.h [modify] https://crrev.com/44e7e44ccad3609ca8acfccfa88768488bb25463/headless/app/headless_shell.cc [modify] https://crrev.com/44e7e44ccad3609ca8acfccfa88768488bb25463/headless/lib/headless_content_main_delegate.cc
,
Aug 2 2017
Tested the issue on Windows7 , Win2008 with chrome #60.0.3112.90
Steps Followed :
1. Installed chrome msi on windows 7 & windows 2008
2. Enabled "Set User Data directory" as "${local_app_data}\Google\Chrome\UserData${client_name}"
3. Updated group policy in client and server using "gpupdate /force"
4. launched chrome in both server and client.
Observations: On launching the chrome browser on both Windows 7 & 2008, observed "Fail to create Data Directory" error dialog box.After closing the box chrome is launched.
Attaching the screen-cast for reference
scottmg@ could you please look into it and confirm that this this is the intended behavior of this fix
Thank you...
,
Aug 2 2017
No, that's not desirable (I would expect it to be "...\UserDatatestuser.SKYTAP" or something, but I'm not sure about the test setup. ${client_name} will only be valid when there's a terminal services session active (I'm not actually sure how to make that happen, but it won't be there on a normal user login).
The inability to read/write the directory seems separate though. Could you confirm that you can manually create the directory at the location in the dialog on that test machine?
,
Aug 2 2017
Tried as per the request in #38. The issue is not fixed in 60.0.3112.90 for a client/server environment configuration.
Behavior in M60
================
Server : Set the policy to :"Set User Data directory" as "${local_app_data}\Google\Chrome\UserData${SKYTAP}"
Client : Shows the error with message: "Failed to create Data Directory"
Policy is NOT getting reflected in chrome://policy (See screenshot)
Behavior in M58
================
Server:Policy set as above
Client : Shows the error with message: "Failed to create Data Directory"
Policy is reflected in client as in chrome://policy.
But manually I am able to create directory in data folder- C:\Users\testuser.SKYTAP\AppData\Local\Google\Chrome\User Data
Regrading the test setup, the machines are VMs with a server and a Win 7 client.
,
Aug 2 2017
Thank you for testing. I was most worried about the inability to write to the user data directory. It sounds like the behaviour has not changed from 58 to 60 (post-revert) here then though. I'm not familiar with the data source for chrome://policy. Not displaying there feels like a less serious regression, and is possibly due to a different change in this area. Anyone else know how that gets populated or have thoughts on what might be busted?
,
Aug 2 2017
Two things are concerning me with those screenshots: - For M58.png the expanded policy is called "GCFUserDataDir" which is the long deprecated and removed Chrome Frame specific policy. I can see the USerDataDir policy is also present above but its contents are not shown. - For M60.png - there are square braces [] around the string. Which also show around the path in the error dialog (also true for the other screenshot). This worries me because this policy is of type string and is supposed to look like "this" not like [this] so I suppose those braces are part of the string and therefore create a path which is always going to be invalid. Can you please verify these two things.
,
Aug 2 2017
Correction to my comment on M60 - the policy should show up even without quotes just the value. However the policy parsing code can handle quotes around the string because this is common mistake. Anyhow the rest of the comment stays relevant.
,
Aug 2 2017
Good catch Julian!(Just to confirm, I don't see the [] in https://cs.chromium.org/chromium/src/chrome/app/chromium_strings.grd?l=329 (nor in the google_chrome_strings.grd) which I believe is where the message is coming from in the video in #c37.)
,
Aug 2 2017
Yes, and we don't post process policy value for the chrome://policy UI either. I just checked with the policies currently set on my Chromebook. I don't have a win box with me right now but this code is not platform dependent.
,
Aug 2 2017
Thanks Julian.
Accidentally did not notice the extra braces. Works fine in latest chrome stable -60.0.3112.90 with user data policy set as "${local_app_data}\Google\Chrome\UserData${SKYTAP}"
As you requested, in M58 also I am seeing the correct path, attaching the screenshot for reference.
Going forward will make sure that this testcase is included as a part of chrome enterprise regression testing.
,
Aug 4 2017
I just wanted to say Thanks for resolving this issue quickly. I can confirm the issue has been resolved.
,
Aug 14 2017
I am getting a similar issue, but not 100%.
When I put out a GPO for Roaming Profile copies, and I have it pointed to "${documents}\Chrome\" I will get a crash for some users the first time they try to launch but not others...
Specifically in the event that the user has used the install before, and is launching AFTER doing a GPUPDATE. Chrome will just instantly close, no errors. However if I have them GPUPDATE while chrome is launched, no issues...
I am going to try and reproduce on my test network at home and I will then be able to give more detail. Does this sound similar enough that you want me to put the information here, or different enough that I should create a new ticket?
Client OS: Win10
Chrome Vs: 60.0.3112.90
Server: Win 2012r2
,
Aug 14 2017
scottmg@/pastarmovj@, can you please look into c#47? Thank you!
,
Aug 15 2017
Can you please share here your set of applied policies? Also try running chrome with the "--enable-logging" flag and then upload the chrome_debug.log file from the User Data directory of Chrome.
,
Aug 30 2017
,
Oct 11 2017
Please mark is as 'Fixed' if we are not making any further updates here.
,
Oct 12 2017
It should be fixed in 62 but I will leave it to scott to close unless he wants to do/check something more on that bug.
,
Oct 15 2017
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by manoranj...@chromium.org
, Jul 26 2017Components: Enterprise
Labels: ReleaseBlock-Stable M-60