renderer processes not working in Windows Server 2008 R2
Reported by
shaymas...@gmail.com,
Jan 3 2017
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 Steps to reproduce the problem: 1. log out 2.log in 3.crashes What is the expected behavior? nothing updates dosent open right What went wrong? not sure Crashed report ID: no How much crashed? Whole browser Is it a problem with a plugin? N/A Did this work before? N/A Chrome version: 55.0.2883.87 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 24.0 r0
,
Jan 4 2017
A family member of mine recently contacted me about this same problem, and I tried installing Windows Server 2008 R2 Standard (build 7601) in a VirtualBox VM and see the same behavior - it looks like every renderer process (web pages, extensions, chrome:// scheme pages) immediately crashes every time. Maybe something wrong with the sandbox? I did clean installs of chrome stable (55.0.2883.87) and canary (57.0.2971.0) and see the same problem in both. cc'ing a few people I know who work on chrome windows
,
Jan 5 2017
Were any crash dumps created? You can look in %localappdata%\Google\Chrome\User Data\Crashpad\reports. If not then can you launch chrome under "windbg -o" (windbg with the -o option, to tell it to debug child processes) and record a crash dump when the renderer processes crash? You can create a crash dump for the current process with: .dump /ma path_to_save_crash.dmp
,
Jan 5 2017
,
Jan 9 2017
Added respective labels to further triage as we do not have the hardware to test from India.
,
Jan 9 2017
All this is Chinese to me ugh sorry
,
Jan 9 2017
Since chrome can't run any renderers, I'm not able to load up about:crashes within chrome, but I did find a bunch of crash dumps in the "User Data"\Crashpad\ directory. I've copied the contents from there into a Google Drive folder (@google.com account accessible only) here: https://drive.google.com/drive/folders/0B18eCv5gL6zGcHJNZ2FGb3d5cDQ?usp=sharing This was with chrome 55.0.2883.87, installed today.
,
Jan 9 2017
Thank you comment #7, that is very helpful. I looked at a couple of the crash dumps and they both show the process halting on a hardcoded breakpoint (int 3) on this call stack:
00 DWrite!ClientAlpcConnection::Create
01 DWrite!ClientSideCacheContext::ConnectToServer
02 DWrite!ClientSideCacheContext::ClientSideCacheContext
03 DWrite!ComObject<DWriteFactory>::ComObject<DWriteFactory><enum DWRITE_FACTORY_TYPE>
04 DWrite!CreateFactory
05 chrome_child!content::?A0x349200f0::CreateDirectWriteFactory
06 chrome_child!content::InitializeDWriteFontProxy
07 chrome_child!content::RendererMainPlatformDelegate::PlatformInitialize
08 chrome_child!content::RendererMain
09 chrome_child!content::RunNamedProcessTypeMain
0a chrome_child!content::ContentMainRunnerImpl::Run
0b chrome_child!content::ContentMain
0c chrome_child!ChromeMain
0d chrome!MainDllLoader::Launch
0e chrome!wWinMain
In other words, the process is failing when it tries to initialize DirectWrite. I'm not sure what changes have happened in that area lately but at least now we can tag this bug with a component and see if we can make some progress.
To the original filer of the bug: I don't know for sure if you are seeing the same issue. If you go to the start menu and paste in this text:
%localappdata%\Google\Chrome\User Data\Crashpad\reports
then that should take you to Chrome's crash report folder. If there are any recent crash report files there then if you could attach some of them to this bug then that will ensure that we can investigate your crashes as well, in case it is a different root cause.
,
Jan 10 2017
,
Apr 10 2017
Closing as per lack of response to comment 8. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by ajha@chromium.org
, Jan 4 2017