brian@  Outstanding! 

Do you have any insight why this script fails on a few machines but not on most? Was there any context logic preceding the script that branches around it for other device types?

Identifying the code helps.  We still need to find out how to make it break on a support team machine.

Can you post the Adblock details, so I can add this to the Workaround list?

It's definitely that script. Here's a test page with nothing else on it, and it will crash Chrome just like the others. Just as before, it's not 100%. It may crash it instantly ten times in a row, but then you can open it again and it will take a few minutes to crash.
http://id2.us/bd130test.html

Adding bd-1-30$script as a custom filter in Adblock will block it on any site where it's named similarly.

I've no idea why it should cause the problem on my Yoga Pro. Their implementation of those sensors may be custom, as it has a physical button that prevents auto-rotation, but it still uses the standard Microsoft driver. (If there were any bundled Lenovo drivers with it, I removed them a long time ago. I use it in laptop mode only.)

pbomm@: There is a Lenovo X1 Yoga user with the site crash problem here
  https://productforums.google.com/d/msg/chrome/Y61R9SAEPBc/5lrkRZs8AwAJ
Can you contact him to rundown the differences with your X1 that cannot repro the problem?

What is the Windows update history on your two Lenovos?

brian@ Which AdBlock extension are you using? (extension ID?).  It may not matter, the AdBlock variants may all support the same filter syntax.  

I'll start with one and expand from there..  
I switched ABP to Stands last year and will check it out later..

It's the regular Chrome Adblock extension version 3.32.1
( Options>Customize>Manually Edit filters and add line bd-1-30$script )

Posted the AdBlock filter news to the main threads:
https://productforums.google.com/forum/#!topic/chrome/iNPoJAQ2ORU
https://productforums.google.com/forum/#!topic/chrome/Y61R9SAEPBc

Brian, thanks again.  Let me know if the posts need corrections.

I can confirm that both on wizzair.com and on easyjet.com there's the bd-1-30 script, which is now blocked by AdBlock. Will see what happens next patch Tuesday.

Hi, 
My OS Build is 17134.228.
I'm assuming you are asking for a list of Chrome extensions? 
I show the following:
Google Docs Offline
Privacy Badger
uBlock Origin

Then under extensions but listed as Chrome Apps:
Docs
Sheets
Slides

Hope that helps!

I posted this on the other forum that Larry was working with us on, but didn't know if it could be helpful here in figuring out the sensor issue:

GDB is showing this error message repeatedly while I am trying to replicate the issue onthe websites I currently have issues with (however the websites are NOT closing while GDB is running and this error is showing)

[Thread 10320.0x4588 exited with code 21]
[New Thread 10320.0x4a18]
warning: ERROR NativeSensorCollectionNotifThread:Sensor is being stopped before thread started polling!:0x00000000

Clearing again some wrong labeling and putting some other labels which hopefully are closer to the the final group of people that could help figure this out. There is nothing to do with "Java" in this bug but actually it is indeed the web platform APIs that cause issues with some hardware that supports touch screens and tablet like features. 

I think this bug and the forum thread here https://groups.google.com/a/googleproductforums.com/d/msgid/chrome-admins/9c412ce2-656c-429b-ae5d-6d94f7358b10%40googleproductforums.com meanwhile have enough information collected by people to help figure out what's wrong. 

pastarmovj@ - Thanks, but the stumbling block remains, being able to repro the problem.  Broken users, for the named sites, always crash.  The dev team with similar hardware doesn't. We even have one user with a Lenovo X1, like the team.

The Windows update history may play a role.  See comments above identifying the win build ID, e.g. 17134.228.

If there is any debug (windows crash files) or config info users can provide, please let us know.

The 2 main Help forum threads are:
https://productforums.google.com/forum/#!topic/chrome/iNPoJAQ2ORU  -technical
https://productforums.google.com/forum/#!topic/chrome/Y61R9SAEPBc  - general

Just tried it, crashed it. Here's the crash report from Windows application event viewer: (Lenovo 3 Pro)

Faulting application name: chrome.exe, version: 68.0.3440.106, time stamp: 0x5b6a37f5
Faulting module name: ntdll.dll, version: 10.0.17134.228, time stamp: 0x6d15b6d7
Exception code: 0xc0000374
Fault offset: 0x00000000000f4d1b
Faulting process id: 0x10dc
Faulting application start time: 0x01d4414f57c235b0
Faulting application path: C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report Id: 172cf40d-5861-4399-91d8-0bc279f76d31
Faulting package full name: 
Faulting package-relative application ID: 

I've attached the report.wer file, too.

Deleted: Report.wer 20.1 KB

Report.wer 20.1 KB Download

/cc reilly@ could this be related to Sensors / DevMotion & Orientation?

 Issue 806977  has been merged into this issue.

 Issue 822629  has been merged into this issue.

+ivanpe@ because this issue has been happening for a while but I've never gotten pinged on it because it appears to only rarely result in a crash report.

A potential crash signature for this issue is: device::PlatformSensorReaderWin::GetSensorForType-037845ed

reilyg@ - Thanks for picking this up.  

Re: why none of these crashes seem to generate crash reports.
This is a severe crash.  If you run Chrome under GDB you can catch it, otherwise Windows catches the ntdll.dll exception (see Brian above).

Probably unrelated, 6/11, Lance, another developer, had an AJAX stale token revocation, that froze Chrome, requiring a kill from task manager.

There are several crash reports mentioned in chrome-admins.  Eric looked at some of these in early May but didn't find much.  

We have active devs/admins/power users who can help log the problem (qwer1, feltonst,..) if you need more.

If you cannot repro the problem, there are again users who are willing to help.  Let me know what kind of machines you're testing on, with their latest Windows update history (17134.xxx), and what kind of config/debug info you need and I'll go digging.

The problem seems to depend on the Windows monthly update cycle.  Pre-workarounds for disabling the sensor or blocking the API call, there were other workarounds (disable USB 3 Host controller, reset flags to defaults and restart) that mostly worked until the next Windows update cycle.

I have months worth of notes if anyone wants to hangout.

My report was merged into this ticket.
1. I have HP Spectre x360 1st generation. Reportedly the same issue exists for Lenovo and does not exist for the 2nd generation of HP Spectre x360
2. Issue exists in Chromium, Chrome and Chrome Canary under Windows 10 both x32 and x64.
2. Solution that finally worked for me - disabling "HID Sensor Collector V2" (driver version 10.0.17134.1 as of 4/21/2009). 
3. It does not look like there is newer version of the driver. 

Unfortunately crash reports expire after a few months so none of the crash IDs I could find on chrome-admins led me to a report I could use. If you do have a recent crash ID or attach a full minidump that would be very helpful.

An example crash report that might be this issue is crash/4125dcac3ab17b41.

From that and similar reports it seems like Chrome is hitting a crash deep inside the COM objects that implement sensor support on Windows. The two stacks I've seen so far are:

(combase.dll -catalog.cxx:3861 )	CComCatalog::GetClassInfoInternal(unsigned long,IUserToken *,_GUID const &,_GUID const &,void * *,void *)
(combase.dll -objact.cxx:1618 )	ICoCreateInstanceEx(_GUID const &,IUnknown *,unsigned long,_COSERVERINFO *,unsigned long,unsigned long,tagMULTI_QI *,ActivationPropertiesIn *)
(combase.dll -immact.hxx:376 )	CComActivator::DoCreateInstance(_GUID const &,IUnknown *,unsigned long,_COSERVERINFO *,unsigned long,tagMULTI_QI *,ActivationPropertiesIn *)
(combase.dll -actapi.cxx:120 )	CoCreateInstance
(SensorsApi.dll + 0x0002abea )	CSensorV2::InitializeStaticProperties()
(SensorsApi.dll + 0x0002b8ae )	CSensorV2::RuntimeClassInitialize(unsigned short const *,_GUID const &,_GUID const &,_GUID const &)
(SensorsApi.dll + 0x000159e8 )	Microsoft::WRL::Details::MakeAndInitialize<CSensorV2,CSensorV2,unsigned short const * const &,_GUID &,_GUID &,_GUID &>(CSensorV2 * *,unsigned short const * const &,_GUID &,_GUID &,_GUID &)
(SensorsApi.dll + 0x000167bf )	CSensorManager::CreateV2Sensor(_DEV_OBJECT const *,ISensor * *)
(SensorsApi.dll + 0x0001806f )	CSensorManager::GetSensorsFromFilterExpression(_DEVPROP_FILTER_EXPRESSION const *,unsigned long,ISensorCollection * *)
(SensorsApi.dll + 0x000179d5 )	CSensorManager::GetSensorsByInterface(_GUID const &,ISensorCollection * *)
(SensorsApi.dll + 0x00017abd )	CSensorManager::GetSensorsByType(_GUID const &,ISensorCollection * *)

and:

(ntdll.dll + 0x00023879 )	InitializeTEBUserLangList
(ntdll.dll + 0x0002af20 )	RtlGetThreadPreferredUILanguages
(KERNELBASE.dll + 0x000dad36 )	GetThreadPreferredUILanguages
(cfgmgr32.dll + 0x0000642f )	GetPreferredLanguageList
(cfgmgr32.dll + 0x0001251e )	TQuery::SerializationRead(void *,char * *,unsigned int *)
(cfgmgr32.dll + 0x00004e35 )	DevGetObjects
(SensorsApi.dll + 0x00017fbc )	CSensorManager::GetSensorsFromFilterExpression(_DEVPROP_FILTER_EXPRESSION const *,unsigned long,ISensorCollection * *)
(SensorsApi.dll + 0x000179d5 )	CSensorManager::GetSensorsByInterface(_GUID const &,ISensorCollection * *)
(SensorsApi.dll + 0x00017abd )	CSensorManager::GetSensorsByType(_GUID const &,ISensorCollection * *)

#74 OK. Any suggestion on how we track down why it only happens on some instances of a hardware model?

Do you need anything besides crash reports?

After latest Windows update on 9/13/18, Chrome Version 71.0.3551.3 (Official Build) dev (64-bit) crashes on wizzair.com, but Chrome Version 71.0.3555.0 (Official Build) canary (64-bit) with Adware filter of bd-1-30 script does not. This is on HP Spectre x360 13.
The crash closes the browser and there's no crash report.
Since I'm OK with the filter preventing the crash, I'm NOT refreshing the HID driver, so I can recreate the crash at will.
Let me know if you want to try some experimental version with e.g. extra logging. 

reillyg@ - Would it help if users re-sent old crash logs?  There are other dumps available (windows, GDB, chrome_debug) and users can generate them as needed with additional flags.

Other comments also point to problem on freeing a sensor object.

Note alik's #73 comment that it may only fail on first gen x360's.  BIOS and driver updates to the latest have been confirmed and the problem persists.  I will dig out the details if you want them.

qwer1@ Did you mean the adblock filter doesn't protect 71.0.3551.3?
Is you x360 first gen?  How can we identify first gen machines?

@larrylac The adblock filter DOES work. Therefore, I do NOT need to refresh the HID driver after Windows update and thus can recreate the problem AT WILL by TEMPORARILY disabling the filter.

My HP X360 is 1st gen. I think you can tell from the model number. Mine is L0Q54UAR#ABA which translates to 13-4013dx. The 0 after the 4 indicates its the 1st gen AFAIK.

@qwer: Tx, that's the simplest read. I was just checking there was no other implication of the 2 distinct canary 71... refs.

Can you give a short description of how to lookup the 4013dx tag at HP? I'm posting news updates to Forum threads, like here
https://productforums.google.com/d/msg/chrome/Y61R9SAEPBc/A7_mtCs2AQAJ

Old crash logs are not useful but a fresh full minidump from qwer1304@ on the latest canary would be very useful. We are also working on a small change to how we communicate with the Windows sensor stack which might help. I will ping this issue when that hits canary.

@larrylac
1.Open HP Assistant
At the bottom of the window there will be the Product Number
2.Click the Product Number to copy it
3a.Either google it, or
3b.Go to https://support.hp.com/us-en/products and enter it in the box Enter your HP serial number, product number or product name
A page will open with your laptop's model number

@reillyg Do you need a minidump now or after you'll have tweaked the code?

A minidump now would be great.

@reillyg Here you go
Crash @ wizzair.com

Deleted: chrome.exe.17892.dmp 3.5 MB

chrome.exe.17892.dmp 3.5 MB Download

Re: limited to Spectre 1st gen.  I scanned the two main forum threads (*EPBc, *2ORU) and found broken reports from several -41xx users.  I don't think this is going to pan out.

*2ORU: pmaljr 4/10 13-4105dx, Tim Leek 4/16 13-4193dx, Damion 4/24 13t-4000CTO, AlecE 4/24 13-4118nr

*2ORU is: 
https://productforums.google.com/forum/#!topic/chrome/iNPoJAQ2ORU

Re: Chrome OK after BIOS update - I don't understand why an (HP) BIOS update, either F.50 or F.51, let Chrome access these sites for ~2 weeks, before finally breaking, sometimes without a windows update, but usually on the next windows update.

There are two reports that reinstalling F.50 (5/22 AlanKris) fixes Chrome again.  David Liles (*EPBc) did the F.50 reinstall each month 6/27, 7/11, 8/15 after the monthly windows update and was good until the next month.

The windows OS drivers are untouched by the BIOS update, but somehow the binary code they use get's healed.  I'm stumped.

@reilyg - If you need dump files of how this fails and/or then works after a BIOS update, for a comparison, I will ask..

Chrome_debug.logs show: 
  ERROR:platform_sensor_reader_win.cc(242)] NOT IMPLEMENTED

This is from chrome Version 67.0.3396.87 (Official Build) (64-bit)
Lenovo Yoga 3 Pro-1370 here
https://productforums.google.com/forum/#!topic/chrome/9y2p38K1K14

Deleted: CR789344 Mary-1K14-67..87-i620 chrome_debug-ext disabled.log 3.3 KB

CR789344 Mary-1K14-67..87-i620 chrome_debug-ext disabled.log 3.3 KB View Download

That is not an error, it just means that the page requested a sensor type that is not available directly from Windows. This log message should likely be removed as it is the expected behavior when a site subscribes to, for example, the 'deviceorientation' event. Chrome will fall back to a different sensor type that is available.

Thx.  Was just beating the bushes for sensor related items.

Any luck on catching the crash logs for this failure mode?

If you need more user inputs/logs/dumps, just ask..

@reillyg Anything useful in the minidump? Need more?

Can you all try the latest Chrome dev-channel release? Version 71.0.3570.0 should have the new behavior I'd like to test.

Looking good so far. My test page at http://id2.us/bd130test.html crashes Win Version 69.0.3497.100 (Official Build) (64-bit) (sometimes I need to refresh a few times before it does it.) 

Seems okay on Version 71.0.3573.0 (Official Build) dev (64-bit) though. I've refreshed a few dozen times with no problems.

(Lenovo Yoga 3 Pro, Win 10)

I CRASHED easyjet.com on Version 71.0.3573.0 (Official Build) dev (64-bit)
(HP Spectre x360 13 L0Q54UAR#ABA, Win 10)
Interestingly, wizzair.com didn't crash.
So perhaps there's an improvement, but not a complete solution yet.

Did the crash generate a crash ID in chrome://crashes? If not can you attach another minidump?

@reillyg No crash ID. Attached a minidum

Deleted: chrome.exe.13260.dmp 3.0 MB

chrome.exe.13260.dmp 3.0 MB Download

@reillyg - Is there a CR or Feature ID or CL where I can see the merge trail? 

Was this implemented in Blink or V8?

The Windows fall feature update 1809 began rolling out 10/9.  We'll need to watch this for impacts.

FYI there was a generic sensor update in Chrome 67 which apparently had no impact on this CR.
https://en.wikipedia.org/wiki/Google_Chrome_version_history

Version 72.0.3590.0 (Offizieller Build) dev (64-Bit)
mobile.de, no crash so far but instead it freezes a few seconds, easily reproducible on that page only making some car searches.
Lenovo Yoga

Also the site from above http://id2.us/bd130test.html freezes build 72.0 instead of crashing.
I'm amazed how long this bug is known and no definitv fix released yet.

I hate to add confusion, but I'm not seeing any issue now on the test page with V71 or V72. Okay on Fidelity and easyjet, too.
Lenovo Yoga 3 Pro

I am also suffering from chrome crashes on lenovo yoga 920. As others have reported it hits me for some known retailers such as homedepot.com. Cannot complete an order without crashing. I just installed the current going beta which as of today is 71.0.3578.30. I had my hopes up and went through a few tests by mass loading my bookmarks etc. Everything until I loaded up homedepot again. Then crash with version as well. I can say that it has not been resolved by google at least as of the version reported. Have not tried anything else recommended in here such as HID driver disabling etc so I cannot say if these solutions work.

efficien@ As others are reporting fixed with v71+ (brian#100, etc), we need more details.

Can you confirm behavior for the usual suspects: clear cache, alternate/new chrome profile...

Does the Adblock filter help or disabling HID Sensor Collection V2?

Other status reports:
https://productforums.google.com/d/msg/chrome/iNPoJAQ2ORU/xwLw_98rAQAJ
11/3, 11/4 George: Some sites still crash in beta 71.0.3578.30, but all are OK with adBlock filter.  Some sites may be OK in beta without the filter, but have a noticeable temporary freeze when first opening.  Note George opened multiple test sites concurrently with a test folder collection of sites.

Using version 70.0.3538.77 (just installed from Beta) and still seeing crashes on usual, java-scripted sites.  Just tried CapitalOne360, chase.com, wellsfargoadvisors.com, and all crash. Windows Surface, Windows 10 Pro v. 1511 OS Build 10586.1176.  Been having this problem for over a year, but first time posting. 

bcatr@ #104 - Does the Adblock filter help or disabling HID Sensor Collection V2 (in device manager).  The Windows Surface PC has been mentioned only rarely (for this failure case).

If the AdBlock filter works for the Windows Surface, or disabling the HID Sensor Collection V2 (may be named differently on a Windows Surface), please let us know.

I field most related user questions in the Chrome Help Forum here:
https://productforums.google.com/forum/#!msg/chrome/Y61R9SAEPBc/uFll5t-JCAAJ

AdBlock Plus filter does not appear to be working on https://chewy.com.

Relatedly is something being done about the fact that Chrome is not generating crash reports here? Not generating crash reports sounds like a larger issue - who knows how bad this and others are in the wild with no crash reports coming in.

bcatr@ #104, bbodenmi@ #106 - Pls test in beta v71, it may be fixed there.

reillyg@, ivanpe@ - It looks like v71 is still failing at easyJet(#93) and homedepot(#101) AND still not generating crash reports.

It's great that m71 fixed part of this but still troubling that there are no crash reports.

I just loaded the minidump attached (comment #95) in WinDBG. It looks like there is a heap corruption caused by double free:

0:044> !analyze -v
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************

GetUrlPageData2 (WinHttp) failed: 12029.

CONTEXT:  (.ecxr)
rax=00007ffdd48d7363 rbx=00000000c0000374 rcx=0000000000000003
rdx=00007ffdd48966ba rsi=0000000000000001 rdi=00007ffdd49e97b0
rip=00007ffdd4984d3b rsp=00000009ac7ff5f0 rbp=000001ad9e970c00
 r8=00007ffdd49a4382  r9=00000009a6dcd000 r10=0000000000000000
r11=00000001ac7ff200 r12=0000000000000000 r13=000001ada7d82470
r14=000001ad9e970bf0 r15=00007ffd66a20d60
iopl=0         nv up ei pl nz na pe nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
ntdll!RtlReportCriticalFailure+0x97:
00007ffd`d4984d3b eb00            jmp     ntdll!RtlReportCriticalFailure+0x99 (00007ffd`d4984d3d)
Resetting default scope

FAULTING_IP: 
ntdll!RtlReportCriticalFailure+97
00007ffd`d4984d3b eb00            jmp     ntdll!RtlReportCriticalFailure+0x99 (00007ffd`d4984d3d)

EXCEPTION_RECORD:  (.exr -1)
ExceptionAddress: 00007ffdd4984d3b (ntdll!RtlReportCriticalFailure+0x0000000000000097)
   ExceptionCode: c0000374
  ExceptionFlags: 00000001
NumberParameters: 1
   Parameter[0]: 00007ffdd49e97b0

PROCESS_NAME:  chrome.exe

ERROR_CODE: (NTSTATUS) 0xc0000374 - A heap has been corrupted.

EXCEPTION_CODE: (NTSTATUS) 0xc0000374 - A heap has been corrupted.

EXCEPTION_PARAMETER1:  00007ffdd49e97b0

NTGLOBALFLAG:  0

APPLICATION_VERIFIER_FLAGS:  0

APP:  chrome.exe

ANALYSIS_VERSION: 10.0.10240.9 amd64fre

LAST_CONTROL_TRANSFER:  from 00007ffdd498c806 to 00007ffdd4984d3b

FAULTING_THREAD:  ffffffff

BUGCHECK_STR:  ACTIONABLE_HEAP_CORRUPTION_heap_failure_block_not_busy_DOUBLE_FREE

DEFAULT_BUCKET_ID:  ACTIONABLE_HEAP_CORRUPTION_heap_failure_block_not_busy

STACK_TEXT:  
00007ffd`d49e9808 00007ffd`d4929a55 ntdll!RtlpLogHeapFailure+0x45
00007ffd`d49e9810 00007ffd`d4937347 ntdll!RtlFreeHeap+0x97127
00007ffd`d49e9818 00007ffd`d1a8d92b ucrtbase!_free_base+0x1b
00007ffd`d49e9820 00007ffd`d1a8d7da ucrtbase!__crt_state_management::wrapped_invoke<void +0x2a
00007ffd`d49e9828 00007ffd`ccbd1b26 sensorsapi!CSensorV2::`vector deleting destructor'+0x26
00007ffd`d49e9830 00007ffd`ccbbc77b sensorsapi!Microsoft::WRL::Details::RuntimeClassImpl<Microsoft::WRL::RuntimeClassFlags<2>,1,0,0,ISensor,ISensorPower,Microsoft::WRL::FtmBase>::Release+0x2b
00007ffd`d49e9838 00007ffd`66a1ff2d chrome_7ffd65a70000!device::PlatformSensorReaderWin::~PlatformSensorReaderWin+0x37
00007ffd`d49e9840 00007ffd`66a20e28 chrome_7ffd65a70000!base::DeleteHelper<device::PlatformSensorReaderWin>::DoDelete+0x12
00007ffd`d49e9848 00007ffd`65a9423c chrome_7ffd65a70000!base::debug::TaskAnnotator::RunTask+0x12c
00007ffd`d49e9850 00007ffd`65a93c37 chrome_7ffd65a70000!base::MessageLoop::RunTask+0x247
00007ffd`d49e9858 00007ffd`65a8cbe8 chrome_7ffd65a70000!base::MessageLoop::DoWork+0x198
00007ffd`d49e9860 00007ffd`65a937c9 chrome_7ffd65a70000!base::MessagePumpDefault::Run+0x99
00007ffd`d49e9868 00007ffd`65a8c631 chrome_7ffd65a70000!base::RunLoop::Run+0x31
00007ffd`d49e9870 00007ffd`65a8a100 chrome_7ffd65a70000!base::Thread::ThreadMain+0x180
00007ffd`d49e9878 00007ffd`66c75824 chrome_7ffd65a70000!base::`anonymous namespace'::ThreadFunc+0xf4
00007ffd`d49e9880 00007ffd`d3083034 kernel32!BaseThreadInitThunk+0x14
00007ffd`d49e9888 00007ffd`d4901461 ntdll!RtlUserThreadStart+0x21


STACK_COMMAND:  dps 7ffdd49e9808 ; kb

FOLLOWUP_IP: 
ucrtbase!_free_base+1b
00007ffd`d1a8d92b 85c0            test    eax,eax

SYMBOL_STACK_INDEX:  2

SYMBOL_NAME:  ucrtbase!_free_base+1b

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: ucrtbase

IMAGE_NAME:  ucrtbase.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  40b70dec

FAILURE_BUCKET_ID:  ACTIONABLE_HEAP_CORRUPTION_heap_failure_block_not_busy_c0000374_ucrtbase.dll!_free_base

BUCKET_ID:  ACTIONABLE_HEAP_CORRUPTION_heap_failure_block_not_busy_DOUBLE_FREE_ucrtbase!_free_base+1b

PRIMARY_PROBLEM_CLASS:  ACTIONABLE_HEAP_CORRUPTION_heap_failure_block_not_busy_DOUBLE_FREE_ucrtbase!_free_base+1b

FAILURE_PROBLEM_CLASS:  ACTIONABLE_HEAP_CORRUPTION_heap_failure_block_not_busy

FAILURE_EXCEPTION_CODE:  c0000374

FAILURE_IMAGE_NAME:  ucrtbase.dll

FAILURE_FUNCTION_NAME:  _free_base

FAILURE_SYMBOL_NAME:  ucrtbase.dll!_free_base

ANALYSIS_SOURCE:  UM

FAILURE_ID_HASH_STRING:  um:actionable_heap_corruption_heap_failure_block_not_busy_c0000374_ucrtbase.dll!_free_base

FAILURE_ID_HASH:  {0f47b90e-515e-908a-6274-f48897558c4e}

Followup:     MachineOwner
---------

Regarding why we are not getting any crash reports (minidumps generated and uploaded to Google), I suspect that the UnhandledExceptionHandler is not called in this case, so Crashpad is unable to capture the minidump. I'm including Bruce, Leonard and Mark Mentovai in case they have any ideas on how to capture minidumps in cases like these.

0:044> knL
 # Child-SP          RetAddr           Call Site
00 00000009`ac7fe438 00007ffd`d496834c ntdll!NtWaitForMultipleObjects+0x14
01 00000009`ac7fe440 00007ffd`d4967656 ntdll!WerpWaitForCrashReporting+0xa8
02 00000009`ac7fe4c0 00007ffd`d4966e1d ntdll!RtlReportExceptionHelper+0x33e
03 00000009`ac7fe590 00007ffd`d4984d95 ntdll!RtlReportException+0x9d
04 00000009`ac7fe610 00007ffd`d491ab36 ntdll!RtlReportCriticalFailure$filt$0+0x33
05 00000009`ac7fe640 00007ffd`d4929aee ntdll!_C_specific_handler+0x96
06 00000009`ac7fe6b0 00007ffd`d492ed2d ntdll!_GSHandlerCheck_SEH+0x6a
07 00000009`ac7fe6e0 00007ffd`d4896c86 ntdll!RtlpExecuteHandlerForException+0xd
08 00000009`ac7fe710 00007ffd`d48952ca ntdll!RtlDispatchException+0x3c6
09 00000009`ac7fee10 00007ffd`d4984d3b ntdll!RtlRaiseException+0x31a
0a 00000009`ac7ff5f0 00007ffd`d498c806 ntdll!RtlReportCriticalFailure+0x97
0b 00000009`ac7ff700 00007ffd`d498cad1 ntdll!RtlpHeapHandleError+0x12
0c 00000009`ac7ff730 00007ffd`d4929a55 ntdll!RtlpHpHeapHandleError+0x5d
0d 00000009`ac7ff760 00007ffd`d4937347 ntdll!RtlpLogHeapFailure+0x45
0e 00000009`ac7ff790 00007ffd`d1a8d92b ntdll!RtlFreeHeap+0x97127
0f 00000009`ac7ff830 00007ffd`d1a8d7da ucrtbase!_free_base+0x1b
10 00000009`ac7ff860 00007ffd`ccbd1b26 ucrtbase!__crt_state_management::wrapped_invoke<void (__cdecl*)(void * __ptr64),void * __ptr64,void>+0x2a
11 00000009`ac7ff890 00007ffd`ccbbc77b SensorsApi!CSensorV2::`vector deleting destructor'+0x26
12 00000009`ac7ff8c0 00007ffd`66a1ff2d SensorsApi!Microsoft::WRL::Details::RuntimeClassImpl<Microsoft::WRL::RuntimeClassFlags<2>,1,0,0,ISensor,ISensorPower,Microsoft::WRL::FtmBase>::Release+0x2b
13 00000009`ac7ff8f0 00007ffd`66a20e28 chrome_7ffd65a70000!device::PlatformSensorReaderWin::~PlatformSensorReaderWin+0x37
14 00000009`ac7ff920 00007ffd`65a9423c chrome_7ffd65a70000!base::DeleteHelper<device::PlatformSensorReaderWin>::DoDelete+0x12
15 00000009`ac7ff950 00007ffd`65a93c37 chrome_7ffd65a70000!base::debug::TaskAnnotator::RunTask+0x12c
16 00000009`ac7ffa70 00007ffd`65a8cbe8 chrome_7ffd65a70000!base::MessageLoop::RunTask+0x247
17 00000009`ac7ffbd0 00007ffd`65a937c9 chrome_7ffd65a70000!base::MessageLoop::DoWork+0x198
18 00000009`ac7ffdc0 00007ffd`65a8c631 chrome_7ffd65a70000!base::MessagePumpDefault::Run+0x99
19 00000009`ac7ffe20 00007ffd`65a8a100 chrome_7ffd65a70000!base::RunLoop::Run+0x31
1a 00000009`ac7ffe50 00007ffd`66c75824 chrome_7ffd65a70000!base::Thread::ThreadMain+0x180
1b 00000009`ac7ffee0 00007ffd`d3083034 chrome_7ffd65a70000!base::`anonymous namespace'::ThreadFunc+0xf4
1c 00000009`ac7fff60 00007ffd`d4901461 kernel32!BaseThreadInitThunk+0x14
1d 00000009`ac7fff90 00000000`00000000 ntdll!RtlUserThreadStart+0x21

ivanpe@ Thx.  Understood: not quite bulletproof.

reillyG@ The #95 minidump is also an m71 (71.0.3573.0) example of a site (easyJet) crash not fixed by the m71 change.  Anything else you need?

From comment 109:
> 06 00000009`ac7fe6b0 00007ffd`d492ed2d ntdll!_GSHandlerCheck_SEH+0x6a

If this is a /GS (buffer overrun protection) crash, those are explicitly denied the user-provided unhandled exception filter. We wouldn’t expect Crashpad to be able to see those, unfortunately. Big known blind spot.

mark@ #111 - The original cause for the exception is back around
>0f 00000009`ac7ff830 00007ffd`d1a8d7da ucrtbase!_free_base+0x1b
which ivanpe@ saw as a double free heap corruption.

Does a bad free always/generally result in a /GS buffer exception which avoids crashpad, or was the bad free just unfortunate in this case to drive through the GS/ blind spot?

While the dump analysis helps understand why there are no crash reports, the real problem is finding a Chrome team platform machine that will fail.  See next comment.
 

pbomm@, kkaluri@ - The critical piece to resolving the sensor crash is to get/find some Chrome team hardware to repro the problem.

I've seen user broken reports on the Lenovo ThinkPad X1, which is OK in the lab.  It must also depend on the model or Windows updates or...  

User's don't use the 1803 baseline 10.0.17134.1, and many are now on 1809.  

It may also depend on the machine being in daily use for sometime after a major update.  There was one user who would reflash his BIOS (to the same version) and the machine would be OK for 2 or 3 weeks, then he would reflash again.  This pattern (OK for 2 weeks after BIOS update, maybe until a windows update) has been reported by many users.

I have one specific hardware ref for a broken Lenovo Yoga 920-131KB.

Most of the reports are for Spectre x360.

If there is an easy way for users to document their model info, let me know and I'll pass it along.

This is ridiculous! Can't Google BUY a machine to resolve a priority 1
problem reported MORE than a year ago??!!

Can't you debug my machine remotely? Or what's the problem with this approach?

mr.david@ #98, #99, #115 - The symptoms you describe do not match the failure modes here.  The sensor problem results in a full crash, not a freeze and effects only some Yoga users.

Please open a Help Forum item, post a reference link here and I will follow up.  Include details about things you've tried and the history of when the problem started.

bis bald..

"The symptoms you describe do not match the failure modes here." ? I also have a crash with the release version! Only with the dev version it freezes!
"and effects only some Yoga users." I have a Yoga 920 13IKB and I sent already 100 Chrome crash reports!

mr.david #117: So far you are the only user (here) mentioning v72 freeze.

brian #100 Yoga 3 Pro reports bd130test.html test page, and commerce sites, previously crashing, now OK in v71 & v72 - no freeze

Sorry, I did not understand that your v72 freeze was a crash in v71 or v70.
The primary failure here does not generate Chrome crash reports.  Please post a couple of the Chrome crash report IDs, so someone can followup.
Other users have reported crashes with the Yoga 920, but never crash reports.  See feltonst@ above. If you have the same failure mode as here, the crash IDs will be a big help.

Do your crashes stop when you disable (in Device Manager) the eXensible USB host controller? This is an earlier workaround that prevents the failure mode here.  See above for USB details.

Sorry for the misread, still trying to see if your pattern matches this CR.

qwer1@  The team Yoga Thinkpad X1 seems like it should be able to repro this problem, but doesn't.  There are plenty of Yoga X1 and several Thinkpad failures mentioned in the forum threads.

Maybe we need to find other ways to expose the problem.  Can you try pmaljr 11/6 Lastpass scenario? from here
https://productforums.google.com/d/msg/chrome/iNPoJAQ2ORU/BCQ9jKgAAgAJ
Search pmaljr to find the related comments.  

You both have Spectre x360 13-4xxx models 
(pmal's is a gen2 13-4105dx, you: 13-4013dx gen1).  

If you can verify the Lastpass autoLogin crash dependency, maybe this scenario will work on a team Yoga also.

Give me a crashing site w/ Login and I will try.
All sites I've tried so far didn't have a login (easyjet, wizzair)

qwer1@ Some of the usual sites mentioned are fidelity.com, homedepot.com, lowes, United, Delta, 

pmaljr used: Same here, happens with Hilton Honors Login, Delta Airlines Login, and other form based sites. Sometimes the login button itself causes the crash on delta.com.

delta.com crashes Chrome Dev, Chrome Canary and Chrome stable eventhough
Adblock filter is present.
Adding ruxitagentjs_2SVfhjqr_10151180821210004 filter to Adblock stops the
crash, but the site doesn't behave well (stucks).
The script is obfuscated and I have neither the time nor the expertise to
analyze it to find what it's doing and whether it's similar to the
previously identified offending script.

 larrylac #118 some IDs:
- 1fad87574f7e1deb
- 2fc6cec7706c8523
- 2b930e6027417c3d 
- e7317a5e49c63d56 
- 8c09ca3bf2046ada 
- 9396bb8e37113e6c 
- 3ecb71466202ca49 
- f59ed41fd96cb8f1 
- 38b3b26a6daa3422 

qwer1@ #122: Thx for pushing it along.  
Did you try Lastpass?  I need to check with pmaljr to see if he used lastpass instead of Chrome password autofill

I don't recognize the ruxitagent ID.  I assume you dug this out of the Delta page?

I didn't try LastPass and Autologin since the site was crashing before I
had a chance to do anything. I did dug the script ID from the page source.

On Mon, Dec 3, 2018, 10:45 PM larrylac… via monorail <
monorail+v2.252274531@chromium.org wrote:

mr.david #123

I'm used to seeing chrome://crashes IDs like
   254621f7-8d26-4719-8d68-833ed7827c82

The IDs you listed don't match any part of this format. Will the team know how to find you IDs?

Are the IDs all recent? (< 2 weeks old)

#126

ID des hochgeladenen Absturzberichts: 4ca7927cb556b933 (lokale Absturz-ID: fb054172-6a4b-48d9-ac9d-13f5d324fcd3)
Absturz am Freitag, 23. November 2018 um 23:10:30 erfasst und am Montag, 3. Dezember 2018 um 19:54:56 hochgeladen

qwer1@ #122: The breakage on your x360 seems to be more severe.

Jeanne, also Spectre x360, F.50 BIOS, reports Delta OK with the adBlock filter
https://productforums.google.com/d/msg/chrome/Y61R9SAEPBc/qVGuNGL6AwAJ

Do you have the WPA2 Spectre update installed?  See Liles 6/27 Spectre x360
https://productforums.google.com/d/msg/chrome/Y61R9SAEPBc/8xA_e4SiCgAJ

#127 translation   #127 date/time Dec 3 22:32 UTC
Uploaded crash report ID: 4ca7927cb556b933 [not in #123 list]
(local crash ID: fb054172-6a4b-48d9-ac9d-13f5d324fcd3)
Crash was captured at 23:10:30 Friday, November 23, 2018 and 
uploaded on Monday, December 3, 2018 at 19:54:56
  [Date/Time probably UTC+2 - Germany]

Mr.David@ Danke der Erweiterung!

> Does a bad free always/generally result in a /GS buffer exception
> which avoids crashpad

No, this is heap corruption (double free) rather than a /GS failure, but heap corruption failures *also* elude crashpad. So, unfortunately, this is another known blind spot and it is expected that we wouldn't get crash reports for these.

Microsoft does get crash reports for heap corruption so we could potentially work with them to get more details.

Presumably the double-free is happening in sensorsapi DLL so we need to work with the owner (Lenovo) to get them to fix their bug. They should be able to identify the cause from one of the crash dumps. If they are doing the double-free then there is nothing else we can do, short of, perhaps, blocking their DLL from loading in the first place.

> Presumably the double-free is happening in sensorsapi DLL so we need to work with the owner (Lenovo) to get them to fix their bug.

My understanding is that SensorsApi.dll comes from Microsoft, not Lenovo. It's of course difficult to know since we don't get all of the crash reports but my sense that it is only a small portion of devices that experience this issue. Blocking the DLL from loading entirely would prevent all sensor APIs from working in Chrome on Windows.

The problem affects both HP Spectre and Lenovo Yoga's, it's not just one vendor.

I think it's true it only affects a small number of these, probably even for a given model.  For broken users, the problem is also ephemeral: after a BIOS update (and boot partition update), the problem is gone until the next Windows update.

I believe the problem started somewhat before the windows 1803 rollout (Nov 2017) maybe after a late Windows 1709 update, which still points to the Windows SensorsApi.dll.

Still the problem has not been regression tested. If a broken user, pushes back to m61, maybe with portableApps 61.0.3163.79 or earlier, and doesn't see the problem, would that provide a handle to fix it from the chrome side?

Chrome Dev 64-bit 71.0.3578.80 crashes on delta.com
No crash report
Adblock trick didn't help (it's a different script; see c122)
Uninstalling and re-installing USB xHCI Compliant Host Controller resolves the issue, as always.
This is on HP Spectre x360 13 (Gen 1)

qwer #133: Thx

How long does the USB xHCI toggle last?  Some DeviceManager toggles back to installed only become effective after the next restart, although they appear active in DeviceManager..  When does Chrome start crashing again
 -after next Chrome session (wait for background processes to close or
  turn them off in Settings...System
 -after next Windows restart
 -after next Chrome update
 -after next Windows update (track from Windows Setting...Updates)

Do you have the Spectre WPA2 update installed?  See Liles 6/27 Spectre x360
https://productforums.google.com/d/msg/chrome/Y61R9SAEPBc/8xA_e4SiCgAJ

I'm trying to understand why the filter doesn't work for you.  It does for most other Spectre users (but it's hard to track reliable reports..)

The filter works, but not on delta.com since it has a different script. See
c122 of mine

On Wed, Dec 5, 2018, 8:18 PM larrylac… via monorail <
monorail+v2.252274531@chromium.org wrote:

Chrome starts crashing again
-after next Windows update (track from Windows Setting...Updates)

I  have the Spectre WPA2 update installed

Next time you can reliably reproduce this please try running Chrome under Application Verifier[1] so that we can attempt to catch the memory corruption that is causing this crash when it first happens.

Once you have it installed add chrome.exe to the list of applications to be stressed and expand the list of Basics checks and disable the Leak checks and Handles and Locks checks. Run Chrome and collect both the output from chrome.exe and the logs saved by Application Verifier.

Chrome will run much more slowly when Application Verifier is enabled so make sure to disable it when you are done.

[1]: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/application-verifier

For best results you really need to run chrome (the browser process anyway) under a debugger - windbg or VS, it doesn't matter. That way when Chrome crashes you can save the debug output and also save a crash dump (.dump /ma crashdump.dmp from windbg) so that we can figure out what is going on.

Why you cannot work with Microsoft/Lenovo, etc. together to fix this? I am also a professional programmer and it is out of my imagination how it can be so difficult to fix this. #137 I'm not installing 3GB to do all that.

1 year already that this is open! You could post the locations your people work at so maybe somebody near with the problem could pass by with the broken hardware? Munich maybe?

George_87 reports, for his Yoga 920, for all (his) bad commerce sites, 
m71 (71.0.3578.30+) avoids the crash, but 
each time a bad site tab gets focus there is a 10-12 Chrome freeze 
(Chrome non-responsive, spinner not displayed, queued events processed after delay).  Adding the adBlock filter has no impact on the delay.

Has anyone else seen this m71 freeze for the bad commerce sites?

George first reported this 11/3.  The short freeze persists in m72.
I've seen one other freeze confirmation, but I have very limited visibility - only what users report on the threads I happen to watch.

Now that the crash has morphed into a delay, would a network log be useful?

George 8.Jan summary here
https://productforums.google.com/d/msg/chrome/iNPoJAQ2ORU/ofnY5oZlCAAJ

@larrylac I tried this on wizzair.com with Chrome Version 73.0.3664.3 (Official Build) dev (64-bit) on my HP Spectre X360 w/o Adblocker.
There was a delay, but then Chrome DID crash. (Actually, it was in the 2nd tab with that site that was opened, after a delay).
As noted before, the crash is not guaranteed to happen, but is VERY frequent.
On Chrome Version 73.0.3665.0 (Official Build) canary (64-bit) the delay is longer (perhaps because I had more tabs open), but with Adblocker there was no crash (as is usually the case).

Lenovo Yoga 920 freezes for a few seconds and spinner pauses on Lowes.com and other sites. Attached is Network Log. 

Deleted: chrome-net-export-log.json 11.6 MB

chrome-net-export-log.json 11.6 MB View Download

I'm having the same issue (freezing for ~12 seconds instead of crashing, now that I'm using v71).  I'm on a Yoga 920 as well, running Windows 10.  I had the sensor disabled to avoid the freezes, but re-enabled it to submit this "net export" log.  The problem did not return right away when I re-enabled the sensor - not until after I restarted the computer (restarting the browser, or signing out and back in did not bring the problem back).

My log is very small.  Before I started it, I had several tabs open, including one at HomeDepot.com, which was freezing every time I switched to it.  I started the log, switched to the HomeDepot tab, tried scrolling up and down without any response (the entire browser freezes - you can't close it or switch tabs, and the cursor doesn't change states as you move it around).

Hopefully this log reveals something - let me know if I can help with any other diagnosis.

Deleted: chrome-net-export-log.json 241 KB

chrome-net-export-log.json 241 KB View Download

I saw you also requested for someone to reproduce the problem while running Chrome in a debugger, and under Application Verifier.  I downloaded the Windows SDK Debugger and Application Verifier, added chrome.exe to the Application Verifier's list, checked the requested boxes (Basic, minus Lock, Handles and Leak), and opened "chrome.exe --incognito" in the window debugger, and reproduced the problem (it only seemed to freeze for about 8-9 seconds, oddly enough, even though everything else was going slower).

But the log produced in Application Verified was essentially empty - just 4 files that all look like this:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<avrf:logfile xmlns:avrf="Application Verifier">
	<avrf:logSession TimeStarted="2019-01-10 : 17:02:46" PID="11872" Version="2"/>
</avrf:logfile>

Is there another log you want from that test?  (I'm not familiar with the windows debugger, so I don't know if there's anything of use to export from there)

Thank you for trying Application Verifier. The main hope from that tool was that it would helps us to understand the crash. If you were able to reproduce the crash while running under Application Verifier then I would want you to save the debugger output (from the output window) as a text file, and save a minidump, and share the two files with me. That would let us understand exactly where the corruption occurred.

Hangs seem like a different issue. Important, but different. For these twelve-second hangs a better type of data to acquire would be an ETW trace. Details on how to record these can be found at https://support.google.com/chrome/a/answer/9025467. Ideally you would start ETW tracing to a file, launch Chrome (without App Verifier enabled) and reproduce the hang. Once Chrome recovered from the hang save the trace buffers and share the .etl file with brucedawson@chromium.org so that I can figure out what is going on.

Sent!  I can't reproduce the crash because I don't know how to install an old version of Chrome, but I reproduced the hang while running an ETW trace, and shared it with you on Google Drive :)  Hope you can find something!

Unfortunately I couldn't find any indication of why Chrome is hung. Curiously, I also couldn't see any sign of Lenovo software in our process. There was software from Microsoft, Google, and Intel and nothing else.

I also couldn't see any place where Chrome waited for a long time and then was woken by another process, which is what I would expect if the Lenovo softare out-of-proc was causing the hang.

It may be that your problem is unrelated. I'd still love to get a crash dump with Application Verifier enabled.

I'm not sure what kind of Lenovo software you were looking for, but I didn't have any actual Lenovo programs running (at least not in the foreground - I do see lots of "Lenovo.Modern..." processes in the trace).  Maybe my trace description was throwing you off (?) because I mentioned the "Lenovo HID Sensor" being enabled (referencing the language in the title of this issue).

Technically I don't think the sensor is Lenovo-specific.  What I do know is that the only difference between when Chrome hangs and when it doesn't is whether the "HID Sensor Collection V2" device is enabled or disabled in Device Manager.  If it's disabled, there's no crash and no hang (and the screen orientation sensor doesn't work).  If it's enabled, v70 crashes and v71 hangs (on certain websites, like Homedepot.com).

I think you're less likely to get a crash dump at this point unless someone has disabled updates and is still running v69 or 70 (although I guess I do see a couple comments from people for whom even v71 is crashing - but it seems to have replaced the crash with a freeze for at least Yoga users).  Is there an easy way to install a previous version in an isolated way, just for testing?

Retitling to avoid confusion...

I was indeed misled by the bug title. I did see some Lenovo processes but I couldn't see any sign that they were waking up Chrome after a long delay. I couldn't see signs of *any* process doing that actually.

But, I looked again and by noting when the browser process suddenly started using more CPU I found the end of the hang. At 12.179695740 s into the trace thread 10116 in the browser process (chrome.exe (8668)) wakes up after sleeping for 9,930,631.321. That is suspicious already but the stack that it wakes up on has a lot of SensorImpl code in it. Part of it is:

  chrome.dll!mojo::SimpleWatcher::Context::CallNotify
  chrome.dll!mojo::SimpleWatcher::Context::Notify
  chrome.dll!mojo::SimpleWatcher::OnHandleReady
  chrome.dll!mojo::Connector::HandleError
  chrome.dll!mojo::internal::MultiplexRouter::OnPipeConnectionError
  chrome.dll!mojo::internal::MultiplexRouter::ProcessTasks
  chrome.dll!mojo::internal::MultiplexRouter::ProcessNotifyErrorTask
  chrome.dll!mojo::InterfaceEndpointClient::NotifyError
  chrome.dll!mojo::StrongBinding<content::mojom::FontCacheWin>::OnConnectionError
  chrome.dll!device::SensorImpl::~SensorImpl
  chrome.dll!device::SensorImpl::~SensorImpl
  chrome.dll!device::PlatformSensor::StopListening
  chrome.dll!device::PlatformSensor::UpdateSensorInternal
  chrome.dll!device::PlatformSensorReaderWin::StartSensor
  chrome.dll!base::internal::LockImpl::Lock

It is woken by thread 20808 (same process) on a COM worker thread stack:

  chrome.dll!base::internal::SchedulerWorker::RunSharedCOMWorker
  chrome.dll!base::internal::SchedulerWorker::RunWorker
  chrome.dll!base::internal::TaskTracker::RunAndPopNextTask
  chrome.dll!base::internal::TaskTracker::RunOrSkipTask
  chrome.dll!base::debug::TaskAnnotator::RunTask
  chrome.dll!base::internal::Invoker<...>::Run
  user32.dll!DispatchMessageWorker
  user32.dll!UserCallWinProcCheckWow
  combase.dll!ThreadWndProc
  combase.dll!ThreadDispatch
  combase.dll!ComInvokeWithLockAndIPID
  combase.dll!AppInvoke
  combase.dll!ServerCall::ContextInvoke
  combase.dll!DefaultStubInvoke
  combase.dll!ObjectMethodExceptionHandlingAction<<lambda_76d9e92c799d246a4afbe64a2bf5673d> >
  rpcrt4.dll!CStdStubBuffer_Invoke
  combase.dll!CStdStubBuffer_Invoke
  rpcrt4.dll!NdrStubCall3
  rpcrt4.dll!Ndr64StubWorker
  rpcrt4.dll!Invoke
  chrome.dll!device::EventListener::OnStateChanged
  ntdll.dll!RtlpWakeSRWLock

Meanwhile *that* thread was woken after 10.0 s by a timer interrupt - a ten-second timer clearly expired. It was waiting on this stack:

  combase.dll!AppInvoke
  combase.dll!ServerCall::ContextInvoke
  combase.dll!DefaultStubInvoke
  combase.dll!ObjectMethodExceptionHandlingAction<<lambda_76d9e92c799d246a4afbe64a2bf5673d> >
  rpcrt4.dll!CStdStubBuffer_Invoke
  combase.dll!CStdStubBuffer_Invoke
  rpcrt4.dll!NdrStubCall3
  rpcrt4.dll!Ndr64StubWorker
  rpcrt4.dll!Invoke
  chrome.dll!device::EventListener::OnStateChanged
  chrome.dll!device::PlatformSensorReaderWin::StopSensor
  SensorsApi.dll!CSensorV2::SetEventSink
  SensorsNativeApi.V2.dll!SensorStopV2_Internal
  KernelBase.dll!WaitForSingleObjectEx

Just a fraction of a second later that thread was woken again by WUDFHost.exe (4560) on this stack (deviating at SensorStopStateChangeNotificationV2)

  combase.dll!AppInvoke
  combase.dll!ServerCall::ContextInvoke
  combase.dll!DefaultStubInvoke
  combase.dll!ObjectMethodExceptionHandlingAction<<lambda_76d9e92c799d246a4afbe64a2bf5673d> >
  rpcrt4.dll!CStdStubBuffer_Invoke
  combase.dll!CStdStubBuffer_Invoke
  rpcrt4.dll!NdrStubCall3
  rpcrt4.dll!Ndr64StubWorker
  rpcrt4.dll!Invoke
  chrome.dll!device::EventListener::OnStateChanged
  chrome.dll!device::PlatformSensorReaderWin::StopSensor
  SensorsApi.dll!CSensorV2::SetEventSink
  SensorsNativeApi.V2.dll!SensorStopStateChangeNotificationV2
  SensorsNativeApi.V2.dll!SensorDeviceIoControlV2
  KernelBase.dll!GetOverlappedResult
  KernelBase.dll!WaitForSingleObjectEx

The readying (waking) thread has WUDFRd.sys, WUDFPlatform.dll, WUDFx02000, and SensorsCx.dll on the stack, among others.

So, progress. We know roughly where the ten second timeout is located, but we don't know if we're doing something wrong or if the sensor driver is.

Joe, Bruce: Thx!

Re: subject/title change (dropped Lenovo)
This is indeed not a Lenovo Yoga specific problem.  It effects HP Spectre x360s also, and all can be mitigated by disabling HID Sensor Collection V2.

Re: root cause: earlier (this CR) minidump crash traces found a double free in the Windows/MicroSoft .dlls: SensorApi.dll or ucrtbase.dll.  Check w/ reillyg #92 about what changed in m71 that modulated the crash to a delay (at most sites).

Re: Installing Chrome 70 for testing.  This is pretty straight forward: start with a 3rd redist of Chrome.  Instructions here:
https://productforums.google.com/forum/#!topic/chrome/UFSYuIr1-80
Chrome-portable still has v69 and v70.  I think slimjet goes back further.
 
To run the old chrome in parallel to current, use a windows chrome shortcut target option for --user-data-dir="TestDirPath".  Profile version compatibility across versions can be an issue, but probably not for v70. If useful, I'll update the rollback instructions.

Re: running under a debugger:  Sometimes the crash does not happen when running under a debugger.  Search the CR for gdb or feltonst..@

Re: Toggling HID Sensor Collection V2 on and needing a restart to trigger the crash: Others have reported this too: after toggle on, no crash until next restart.  I don't recall, if after enabling the sensor, but before restart, if you change from landscape to portrait orientation, if Chrome senses the change - which would confirm that the sensor was indeed active and available.

I'll try to get that old version installed if I can find time, and see if I get the same error as feltonst...@ or a crash under the debugger.

Meanwhile, regarding toggling the sensor on and off, I'm not sure how to tell if the sensor is available to Chrome specifically, but when I enable it, without restarting, it does work (i.e. when I flip the computer over, the screen flips)

I tried the demo at https://intel.github.io/generic-sensor-demos/sensor-info/build/bundled/ to see if I could tell whether Chrome could access the sensor, but even after restarting the computer, that was returning a "NotReadableError" for both orientation-related sensor APIs.  So I don't think that's a reliable method and don't know of another way to test Chrome's interaction with the sensor.

Is there a good place to file a bug report for the sensor driver itself?  (or has anybody done so already?)  Looks like it is indeed a Microsoft driver according to Device Manager (see attachment), right? Is this the other place you're hypothesizing the issue could be resolved?

Deleted: Screenshot 2019-01-14 10.20.16.png 15.7 KB

	Screenshot 2019-01-14 10.20.16.png 15.7 KB View Download

Joe #152 Re: toggling sensor driver.

If you flip the device and the screen flips, I think that confirms the sensor is active, particularly if the screen doesn't flip when the sensor is disabled.

Some users report the commerce sites don't crash after enabling the sensor, but do crash after restart (with the sensor enabled).  Is that true for you?

When you fold the keyboard under, you can use the Lenovo as a touchscreen tablet, in either portrait or landscape mode. Did you try the touchscreen keyboard as well, i.e. available when collapsed and sensor enabled, in both orientations?

The sensor drivers are indeed part of Windows.  Sorry, I don't have a recommendation on how to file a bug with Microsoft. I've posted issues, but never got an adequate response.

I'm not sure how the drivers relate to the BIOS, which would be outside the Microsoft scope.  BIOS updates were one of the earlier (temporary) workarounds for this problem, but usually failed on the next Windows update.

"Some users report the commerce sites don't crash after enabling the sensor, but do crash after restart (with the sensor enabled).  Is that true for you?"

Yup! That's exactly it. When I enable the sensor, it starts working (flipping the screen and offering to enter tablet mode, etc.), but the commerce sites are still fine (no crash or freeze) until after I restart the computer.