New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 264 users

Comments by non-members will not trigger notification emails to users who starred this issue.
Status: Fixed
Owner:
Closed: Aug 2015
Cc:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment
Win64 Chrome is crashing in windows 10 insider preview 10525
Reported by yevgenik...@gmail.com, Aug 18 2015 Back to list
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.10525

Steps to reproduce the problem:
1. open google chrome
2. crash
3. 

What is the expected behavior?
chrome is crashing when i open it

What went wrong?
crash

Crashed report ID: no

How much crashed? Whole browser

Is it a problem with a plugin? No 

Did this work before? Yes in the RTM windows 10

Chrome version: 46.0.2478.0  Channel: dev
OS Version: 10.0
Flash Version: Shockwave Flash 18.0 r0
 
Untitled.jpg
201 KB View Download
Comment 1 by bac...@gmail.com, Aug 18 2015
I'm seeing the same issue on the stable channel, version 44.0.2403.155
Comment 2 by Deleted ...@, Aug 18 2015
same problem here!
Beta channel (v45) and Canary channel (v46) all tabs and extensions crash.
Comment 4 by izs...@live.ru, Aug 18 2015
Can confirm the issue with Chrome 46.0.2478.0 (64-bit) on Windows 10.0.10525.

However, it works with --no-sandbox flag.
64 bit version crashes for me, but 32 bit version is ok.
Comment 6 by bruml...@gmail.com, Aug 18 2015
poke for same issue, all tabs and extensions continually crash on Chrome 46.0.2478.0 (64-bit) on Windows 10.0.10525

same on release, beta and dev...
Same here 
Comment 8 by Deleted ...@, Aug 18 2015
And here, running beta, and the --no-sandbox works for me as a workround
Labels: Needs-Feedback
Thanks for filing. Could someone please post the Crash ID# from chrome://crashes?
I cannot even access chrome://crashes -- literally nothing loads. I cannot even access About Chrome. 
Comment 11 Deleted
Fixed by uninstalling and installing 32bit. I was on 64bit
Same issue, it only starts with --no-sandbox flag
64-bit.  As others noted, --no-sandbox works around the issue.  Unfortunately, there are no entries in chrome://crashes
Status: Untriaged
Not sure if this is an issue with us or an issue with the Windows preview build.
Comment 16 Deleted
Comment 17 by cmaso...@gmail.com, Aug 19 2015
Can confirm that disabling the sandbox is a workaround on latest Canary. Tried to get a log too, but the only errors are
"[6072:6408:0818/184856:ERROR:child_process_launcher.cc(444)] Failed to launch child process". The rest is just verbose stuff & warnings about the tabs not loading.
Comment 18 by Deleted ...@, Aug 19 2015
As others noted, issue started directly after install of build 10525.
Comment 19 by rylan...@gmail.com, Aug 19 2015
I have the some problem, with the dev channel.
Same exact problem for me the chrome betas, same work around. The newest insider preview adjusted how windows manages memory, not sure if that is part of the problem as the crash mentions memory.
Comment 21 by tehkr...@gmail.com, Aug 19 2015
from https://blogs.windows.com/bloggingwindows/2015/08/18/announcing-windows-10-insider-preview-build-10525/

Memory Manager Improvements:

In Windows 10, we have added a new concept in the Memory Manager called a compression store, which is an in-memory collection of compressed pages. This means that when Memory Manager feels memory pressure, it will compress unused pages instead of writing them to disk. This reduces the amount of memory used per process, allowing Windows 10 to maintain more applications in physical memory at a time. This also helps provide better responsiveness across Windows 10. The compression store lives in the System process’s working set. Since the system process holds the store in memory, its working set grows larger exactly when memory is being made available for other processes. This is visible in Task Manager and the reason the System process appears to be consuming more memory than previous releases.
Comment 22 by Deleted ...@, Aug 19 2015
Same problem here, all the channels.
Comment 23 by Deleted ...@, Aug 19 2015
Same problem here.
In my case, every extension and tabs crashes, but the browser loads.
Every chrome:// pages crash too.

--no-sandbox is a good workaround for the time being (but I don't really appreciate the loss in security)

Windows build #10525 changes memory management so that's certainly what breaks Chrome.

Win 10 64 bits & Chrome beta 64 bits
Comment 25 by Deleted ...@, Aug 19 2015
As others noted, issue started directly after install of build 10525.
Comment 26 by Deleted ...@, Aug 19 2015
Can confirm that all branches of x64 builds crash on my end as well, build 10525.
Switching to x86 builds as a workaround or using --no-sandbox flag works as well.
Having similar non-functionality with Mozilla Firefox Nightly 64-bit.  To get it functioning, I disable the e10s function.  I assuming this is Mozilla's equivalent of the sandbox.  So, if the Windows build crashes both Firefox and Chrome, but runs Edge fine, is this a problem caused by Microsoft or errant coding by Chromium?
Comment 28 by Deleted ...@, Aug 19 2015
Chrome is a hybrid 32-Bit application with some (very little) 64-bit code. Not sure why they're still using obsolete 32-bit interfaces in a modern world.

Using command line switches or 32-bit browser code is a bad idea.

Fix the browser.
On the Insider Hub of Windows, the status code is saying that "We have received the feedback and are looking into it"

I think we should wait until Microsoft has said something about it, because this might not be a browser issue at all.

I reverted to the stable build so i don't have the insider hub anymore so i can't link it either. 


Cc: jsc...@chromium.org hodie@chromium.org forshaw@chromium.org
Labels: Proj-Windows10 M-46
Owner: wfh@chromium.org
Status: Assigned
wfh@ - Cutting through the noise, it looks like the sandbox is breaking in the Win10 10525 previews for 64-bit Chrome. Do you have an insider build to take a look at this? If Firefox e10s is also breaking as well, then it must be something pretty basic, like our hooks breaking under CFG. So, maybe we just need to fix  issue 510170 ?

forshaw@ - CCing you in case you're curious.

Summary: Win64 Chrome is crashing in windows 10 insider preview 10525 (was: google chrome is crashing in windows 10 insider previw build 10525)
Cc: scottmg@chromium.org
Comment 33 by wfh@chromium.org, Aug 19 2015
yes I have a build 10525 and can confirm 32-bit chrome works but 64-bit doesn't

I also suspect it's the service resolver hooking.
 Issue 522550  has been merged into this issue.
Comment 35 by Deleted ...@, Aug 19 2015
same problem here!
Labels: -Needs-Feedback
We have the problem confirmed and someone is working on it, so additional "me to" comments are a distraction at this point. Please just star the issue if you want to convey that you are affected, and if we have any questions or need additional feedback we'll post a comment.

Also, please remember that this kind of temporary breakage is expected for users on the Windows 10 fast ring. So, we definitely appreciate your assistance in tracking down these problems, but if you're not comfortable dealing with disruptions and workarounds, then the fast ring might not be for you.

Comment 37 by Deleted ...@, Aug 19 2015
You are relying on the System Service Call Stub ASM layout on the 64bit kernel. That is beyond wrong. Why are you relying on that? It is incredibly fragile and hinders Microsoft's ability to innovate.
Comment 38 Deleted
 Issue 522615  has been merged into this issue.
Comment 40 by wfh@chromium.org, Aug 19 2015
win 8 stub:

 4c8bd1           mov     r10,rcx
 b854000000       mov     eax,54h
 0f05             syscall
 c3               ret

win 10 stub:

 4c8bd1           mov     r10,rcx
 b855000000       mov     eax,55h
 f604250803fe7f01 test    byte ptr [SharedUserData+0x308 (00000000`7ffe0308)],1
 7503             jne     000000fc`b2dcec95
 0f05             syscall
 c3               ret

looks like this is CFG
Comment 41 by Deleted ...@, Aug 19 2015
It isn't due to CFG. The underlying issue is still that Chrome is relying on the ASM layout. That makes no sense, and is no wonder it is so fragile when windows updates.
I found a temporary fix for the crashing of Google Chrome 64-bit in Windows 10 build 10525: http://betanews.com/2015/08/19/windows-10-build-10525-breaks-chrome-heres-how-to-fix-it/

"It appears the problem only affected 64-bit versions of Windows, and it's not clear how many people have experienced the issue. The simple solution to getting Chrome up and running again is to use the --no-sandbox flag. This is not something that is normally recommended, as it brings Chrome processes out of their protected, sandboxed state, but as a temporary measure -- and to avoid having to switch browsers for too long -- it's fine.

Right click on the desktop shortcut to Chrome and select Properties.
Move to the Shortcut tab and click in the Target field.
Type a space at the end of the path that appears in the field followed by --no-sandbox.
Hit OK, and use the shortcut to launch Chrome.

You'll notice an information bar at the top of the screen that reads "You are using an unsupported command-line flag: --no-sandbox. Stability and security will suffer" but Chrome will at least be working once again."

Looks like this is reversible once Google releases an update to fix this crashing issue by simply going back into the shortcut properties for Chrome on your desktop and remove " --nosandbox"
Comment 43 Deleted
Comment 44 Deleted
Comment 45 Deleted
I appreciate Google staff is working on the issue, and I do expect it to be fixed promptly. I don't mean to clog the issue with another simple 'me too', but rather I have an additional question.

I am NOT on the Windows Insider program so I shouldn't be no the fast ring, right? I got my updates automatically from Windows 10 instead. Was this update rolled out from the Insider program to the general public by Microsoft? 
This update was NOT released to the general public, only to Insiders on the Fast Ring. If you're not currently on Build 10525 then there's nothing to worry about.
According to Windows, it doesn't say I'm an Insider. If I click 'Uninstall Latest Preview Build' it just takes me to the Settings > Recovery section and doesn't mention anything Insider related.

I did upgrade Windows 10 from Windows 8.1, but I don't recall agreeing to receive Insider updates and if I click Get Started, it gives me the whole schtick about signing up for it. 

Of course I mention this because I too am having the problem, it's just that I don't recall being in the Fast Ring. How can I remove myself from the fast ring if Windows thinks apparently that I'm already on it?
Screenshot 2015-08-19 19.55.33.png
57.1 KB View Download
Screenshot 2015-08-19 19.56.21.png
74.6 KB View Download
#48, if you do Win+R, and run "cmd", it'll print your Windows version. If you're on Fast it'll be 10525, otherwise 10240.
I am NOT on the fast ring then.


Screenshot 2015-08-19 20.06.20.png
13.8 KB View Download
It appears people here having the 'Aw Snap!' message? I get the 'He's Dead Jim' error? i'm on the preview build though? is it the same thing.

The --No sandbox solution didn't work for me either.
Comment 52 by Deleted ...@, Aug 20 2015
I wonder if it could be graphics card driver related? I have Nvidia and had just updated to the current version before updating to the IP build 10525 and noticed that after the upgrade, the graphics driver updated again and that's when issues started. I notice that graphics are drawing slightly with a delay, almost like there is heavy load on the system and there is not. Chrome when I go to open shows the page crashed, then all extensions show crashed, and any attempt to change pages show in the address bar but the image in the window does not change.
Comment 53 Deleted
I am on Fast Ring, x64, stable and Canary channels' 64bit builds both break. However on stable, it's the "He's Dead Jim" error (purple screen?) and using '--no-sandbox' doesn't fix it. Canary gets the 'Aw Snap!' error which the '--no-sandbox' switch does work. Don't think it'll be graphics card related as I'm just on (1st gen) Intel integrated HD graphics (drivers are DX10, even on Win10).
Comment 55 by Deleted ...@, Aug 20 2015
I am using the 500 series Nvidia graphics which I believe was known to be
having issues with Windows 10 as it was noted they were continuing testing.
WU update to version 353.82 dated 8/7 back from 355.60 8/6. Going back to
355 for the moment.
Comment 56 Deleted
Comment 57 Deleted
Comment 58 Deleted
Comment 59 Deleted
Comment 60 Deleted
From the inside feedback it appears other browsers are broken by 10525 too, and I've just found today that the latest "virtualbox" test build fails too. Just fyi.
Comment 62 Deleted
Comment 63 Deleted
Comment 64 Deleted
Comment 65 Deleted
Comment 66 Deleted
Comment 67 Deleted
Comment 68 Deleted
Comment 69 Deleted
Comment 70 Deleted
Comment 71 Deleted
Comment 72 by wfh@chromium.org, Aug 20 2015
I snipped off an important part of code in #40 - the full stub is

 4c8bd1          mov     r10,rcx
 b855000000      mov     eax,55h
 f604250803fe7f01 test    byte ptr [SharedUserData+0x308 (00000000`7ffe0308)],1
 7503            jne     000000fc`b2dcec95
 0f05            syscall
 c3              ret
 cd2e            int     2Eh
 c3              ret

which basically does a check in shareduserdata then if necessary calls the legacy int 2e handler.
I agree with the 10525 mem mgr changes.  Compression and allocation.  ALL extensions die instantly.  x86 is fine.  x64 croaks.  Browser loads, but can't do anything.
I know there were System Call Stub Changes... Perhaps this article will be helpful unless they have changed WOW64 since 10525: http://www.malwaretech.com/2015/07/windows-10-system-call-stub-changes.html
Project Member Comment 75 by bugdroid1@chromium.org, Aug 20 2015
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1453ac3a6d190b21e04d578d5cf71ce19877db47

commit 1453ac3a6d190b21e04d578d5cf71ce19877db47
Author: wfh <wfh@chromium.org>
Date: Thu Aug 20 21:48:05 2015

Add support for int 2e fallback system call stub in Win10.

BUG= 522201 
TEST=sbox_integration_tests on Win 10 build 10525

Review URL: https://codereview.chromium.org/1291043003

Cr-Commit-Position: refs/heads/master@{#344588}

[modify] http://crrev.com/1453ac3a6d190b21e04d578d5cf71ce19877db47/sandbox/win/src/service_resolver_64.cc

Comment 76 Deleted
Comment 77 by wfh@chromium.org, Aug 20 2015
Status: Fixed
this should be fixed in next canary - 46.0.2489.0 and later
Stable?  
Comment 79 by wfh@chromium.org, Aug 20 2015
Depending on the stability of this change we will try and get it into the next major release of Chrome.

Insider builds (fast and slow rings) for Windows 10 are not guaranteed to always be stable, since they are often internal builds - "some software might not install or work correctly" [1].

My recommendation would be that if you are using your PC for any important work you don't opt-in to insider Windows 10 builds.

[1] http://windows.microsoft.com/en-us/windows/preview-faq
#79 I am glad to know now that Insider builds are going to run into problems like this, so I will avoid them in the future. However, as I have shown in a screenshot before in #50, I ran into this issue and I am not actually on build 10525, I'm on 10240. Is there anything extra I might need to do to ensure I don't run into a problem like this when I am not an Insider to begin with? 
Comment 81 by wfh@chromium.org, Aug 20 2015
Re: #80 sounds like you have another issue so please raise a separate bug for it and we can discuss it there. Please supply crash ids in the bug, if you have them.
Comment 82 Deleted
Regards #79...  I am on a stable 10240 build, released to the public and RTM.  I am also, by choice, as an Insider since 10/14.  I DO understand the implications of a test build.  You are NOT addressing a novice! I simply am pointing out there may be conflicts in 10525.  I am not pointing fingers in any direction... simply stating facts. Take the evidence as it may be...........
Comment 84 by Deleted ...@, Aug 21 2015
The Chrome update installed this evening for me. As a software developer myself, I think we should commend Google for the rapid response. This issue was within some core code in the browser - so changes here potentially could affect critical base components of Chrome. The design is well thought out enough so that a major memory manager level issue could be amended in 48 hours and the browser remains functional.
Nice job.
#84 What update??? What channel??? For Canary, my version number is still "46.0.2488.0 canary (64-bit)"
Same here, on Windows Server 2016 TP 3.
Comment 87 by Deleted ...@, Aug 21 2015
Canary build 46.0.2489.0 has just been published and it works on Windows 10 build 10525. Great job guys, thanks very much!
canary 2489.PNG
11.7 KB View Download
Chrome 46.0.2489.0 Canary.PNG
63.8 KB View Download
Comment 88 by Deleted ...@, Aug 21 2015
Will we see the fix pushed to the stable build?
Ok, my copy of Chrome Canary has just updated to "46.0.2489.0 canary (64-bit)" and I removed the " --nosandbox" flag from the shortcut for Chrome Canary and I can confirm it runs perfectly without any problems on build 10525.
Should I back into Canary, or just stay with 32-bit and wait for stable x64? My Insider 10525 is a test system....  just looking for some advice....
@90: This is a bug tracking site.

Advice can be requested here: https://productforums.google.com/forum/#!forum/chrome

Sorry for being so unhelpful...
Comment 92 by bkin...@gmail.com, Aug 21 2015
confirmed on my Chrome-Canary build also.  Works without flags.
Great job!
#91.  Sorry.  Did not mean to tread on site focus.  Will go elsewhere..... 
Comment 95 by wfh@chromium.org, Aug 21 2015
Cc: amineer@chromium.org
Labels: -M-46 M-45 Merge-Request-45
merge requested to M45
Comment 96 by amin...@google.com, Aug 21 2015
Labels: -Merge-Request-45 Merge-Approved-45
Merge approved for M45 branch 2454.
Project Member Comment 97 by bugdroid1@chromium.org, Aug 21 2015
Labels: -Merge-Approved-45 merge-merged-2454
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/034bd64db1806d85b2ceacc736074ac07722af4a

commit 034bd64db1806d85b2ceacc736074ac07722af4a
Author: Will Harris <wfh@chromium.org>
Date: Fri Aug 21 17:23:10 2015

Merge M45: Add support for int 2e fallback system call stub in Win10.

BUG= 522201 
TEST=sbox_integration_tests on Win 10 build 10525

Review URL: https://codereview.chromium.org/1291043003

Cr-Commit-Position: refs/heads/master@{#344588}
(cherry picked from commit 1453ac3a6d190b21e04d578d5cf71ce19877db47)

Review URL: https://codereview.chromium.org/1308563005.

Cr-Commit-Position: refs/branch-heads/2454@{#394}
Cr-Branched-From: 12bfc3360892ec53cd00fc239a47e5298beb063b-refs/heads/master@{#338390}

[modify] http://crrev.com/034bd64db1806d85b2ceacc736074ac07722af4a/sandbox/win/src/service_resolver_64.cc

Comment 98 by Deleted ...@, Aug 21 2015
@wfh. All you have done is handle the new stub format. However that is still fragile, and will break in the future if it changes. These stubs are not designed to have dependencies taken on it.
Is it possible to have this merged to stable build as well? Or is the 45 version going to be promoted to stable soon?
Cc: penny...@chromium.org
Unlikely to make it to 44, though +pennymac in case any more updates are planned.  You won't have to wait very much longer though, 45 isn't too far off.
Definitely won't be another M44 refresh at this point.  Patch will hit stable with M45 promotion soon.
Basically the change allows 32-bit code to go directly to the kernel without going through user-mode WOW64 translation I think. int 2e is used because it is the only way that works on both Intel and AMD processors.
Comment 103 by wfh@chromium.org, Aug 21 2015
#102 64-bit native code will never go through the WOW64 layer. The current guess is that this change might be for hypervisor support, as going through an int 2e handler makes adding code to support that easier.
Sorry, I think I confused it with the change in original Win10 (pre-10525).
Comment 105 by Deleted ...@, Aug 21 2015
Now 32-bit version wont even install on the build 10525
after update 10525 installed google internet stopped functioning with the "aw snap" and no load and the usual send back. 

Is this a compatible issue with windows 10 and google?

When will there be an update to correct problem??

Comment 107 by Deleted ...@, Aug 23 2015
Chrome Canary (64 Bit) works.
Chrome (32 Bit) works.
Chrome (64 Bit) crashes.
Untitled.png
216 KB View Download
Comment 108 by Deleted ...@, Aug 24 2015
There is no need to add additional comments. Chrome 64 Bit will work once Chrome 45 is released, which will be soon.
Cc: kavvaru@chromium.org
Labels: Needs-Feedback
Tested the issue on windows 10 using chrome latest version 47.0.2492.0 with the below steps

1.Opened chrome with flag --no-sandbox
2.Opened chrome without flag --no-sandbox
3.chrome opened on 2 cases
4.Not observed any crash

Please find the attached screen cast and confirm anything missed here.
wfh@Could you please provide the repro steps to verify the issue from test team end.

Thanks,
522201.mp4
1.3 MB Download
Hi,

Why were you and are you still (https://chromium.googlesource.com/chromium/src/+/034bd64db1806d85b2ceacc736074ac07722af4a%5E%21/) relying on undocumented Windows internals in Chrome? This is very hacky, unmaintainable, and leads to future incompatibilities.
Comment 111 by stan...@gmail.com, Aug 25 2015
Why were you and are you still (https://chromium.googlesource.com/chromium/src/+/034bd64db1806d85b2ceacc736074ac07722af4a%5E%21/) relying on undocumented Windows internals in Chrome? This is very hacky, unmaintainable, and leads to future incompatibilities. Can only repeat that :(
Comment 112 by Deleted ...@, Aug 25 2015
@Kavv I noticed you're using an older build of Windows 10 (build 10074). This issue only occurs on the latest 10525 build. Please upgrade your Windows 10 build to the newest one and try running Chrome again.
Labels: Restrict-AddIssueComment-EditIssue
I'm going to closing this out for comments, since the specific issue here is fixed and there will be no future work on this bug. For the small number of people asking why Chrome checks signatures on the 64-bit syscall stubs, it's because doing so significantly mitigates issues from third-party software hooking inside Chrome's sandboxed processes. Whereas on 32-bit Windows we're forced to use much more permissive hooking, and as a result we see far more issues due to malfunctioning third-party software such as AV or other utilities that: break ASLR, leak privileged objects, or just introduce general instability that leads to very high crash rates inside our sandboxed processes.

We will continue to track the impact of our 64-bit syscall stub validation, and if we see significant conflicts in the future we can revisit our decision. But for now, our crash report data supports the position that the strict validation is providing a real end-user benefit in terms of stability and security.

Labels: TE-NeedsTriageFromMTV
Request MTV team to look into the above issue.

Thank you!
Cc: pbomm...@chromium.org
 Issue 526907  has been merged into this issue.
Sign in to add a comment