I think we're going to need the version numbers of the OS and Chrome, also is this 64-bit or 32-bit - is there any way to gather this information from the blog post replies?

Thank you wfh@. I added a comment to blog post asking users to add more info here to the bug.

We got another report of that on the admin forum https://productforums.google.com/forum/#!topic/chrome-admins/8nfjFQ_ncL0 I asked the user to provide more feedback on this bug as well.

Hi 

I am coming from the admin forum after reporting this. I will collate the information you require and update you shortly.

I'll also try to get you some debug logs from windows after the BSOD.

I'll back back with the detais shortly.

Thanks

Hey so here are the details

----------------------------------------
OPERATING SYSTEM : WINDOWS 7 - 32BIT

GOOGLE CHROME VERSION
GoogleChromeStandaloneEnterprise.msi- 63.0.3239.84 (32bit)

MICROSOFT APPLICATION VIRTUALISATION SEQUENCER VERSION - 4.6.3.24870 (32BIT)
----------------------------------------------

I have attached a dump file generated from BSOD. ( let me know if need converting)...

I am running a Hyper V VM - that is with the above config - win 7 32bit + App v 4.6 Sequencer. I think the attached xml give some detail on the hyper v vm!

------------------------------------------------

When I start running through the sequencing process the VM would blue screen a few minutes into running the msi. This has not happened on previous versions.

I have also downloaded 63.0.3239.90 beta and the issue persists...

If you require any more info. Please let me know.

Deleted: 121417-8531-01.dmp 153 KB

121417-8531-01.dmp 153 KB Download

Deleted: WER-31515-0.sysdata.xml 181 KB

WER-31515-0.sysdata.xml 181 KB View Download

Hi

We experiencing also this issue on W2K8R2 Terminal Servers with Appv 4.6 and Chrome  (63.0.3239.84 (Official Build) (32-bit) (cohort: Stable)

is there any kind of status/progress update for this issue?

Hey Ashley 

I also posted on tech-net app v . 

Here is the response via this link...

https://social.technet.microsoft.com/Forums/en-US/0c5bdec3-8ed3-4e45-bd90-87277dab3145/app-v-46-google-chrome-630323984-32bit-bsod-bad-pool-header?forum=mdopappv

Waiting to see what chromium guys reply. I am hoping there will be a fix on this side otherwise I will not be able to progress at all. 

Hi Haroona,

thnx for the reply. 

And indeed if i read the reaction of Microsoft our only hope is that chrome comes with a workable fix/solution.

We have the same issue with Chrome. Starting Chrome from an App-V 4.6 Sequence will cause BSOD. This also happens with the 108 version of Chrome.

Bumping to p1 to prioritize repro/investigation.

Adding "RBS" label for tracking.

 blumberg@, Is this bug applicable to iOS?

Hi

we are experiencing the same issue when starting Chrome from App-V 4.x hosted applications on XenApp


Erlend

I am pretty sure this has nothing to do with iOS :)

Hi guys, I started to have the same issue this morning with Chrome not sequenced in App-V, but with an app sequenced in App-V.
So for this to happens, it seems it only required to have an app virtualized in App-V and interaction with Chrome.

This seems to started happening in Chrome 63.xxx versions.
Because I had a machine with Chrome version 62.xxx and this problem didn't happen, but after updated the browser, it starts happening as supposed to.

So, so far a workaround maybe to uninstall, install Chrome Version 62.xxx and disable the auto-update or update whatsoever

Can someone using App-V 5+ please confirm whether Chrome is working well with this version?

Hello haroonayub,

would it be possible to capture a full memory dump of the crash instead of the small one so that the cause in the user processes is also available?

Thank you!

analyze from a full dmp file:


Microsoft (R) Windows Debugger Version 6.3.9600.16384 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\temp\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available


************* Symbol Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7601 (Service Pack 1) MP (2 procs) Free x64
Product: Server, suite: TerminalServer
Built by: 7601.23915.amd64fre.win7sp1_ldr.170913-0600
Machine Name:
Kernel base = 0xfffff800`0181c000 PsLoadedModuleList = 0xfffff800`01a5e750
Debug session time: Thu Dec 21 08:35:06.786 2017 (UTC + 1:00)
System Uptime: 0 days 5:13:48.506
Loading Kernel Symbols
...............................................................
................................................................
.........................................
Loading User Symbols
PEB is paged out (Peb.Ldr = 00000000`fffdf018).  Type ".hh dbgerr001" for details
Loading unloaded module list
.....
ERROR: FindPlugIns 80070005
ERROR: Some plugins may not be available [80070005]
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 19, {20, fffff8a00e352810, fffff8a00e352830, 5020411}

*** ERROR: Module load completed but symbols could not be loaded for Sftplaywin7.sys
Probably caused by : Sftplaywin7.sys ( Sftplaywin7+173de )

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

1: kd> !analyze -v
ERROR: FindPlugIns 80070005
ERROR: Some plugins may not be available [80070005]
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

BAD_POOL_HEADER (19)
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.
The internal pool links must be walked to figure out a possible cause of
the problem, and then special pool applied to the suspect tags or the driver
verifier to a suspect driver.
Arguments:
Arg1: 0000000000000020, a pool block header size is corrupt.
Arg2: fffff8a00e352810, The pool entry we were looking for within the page.
Arg3: fffff8a00e352830, The next pool entry.
Arg4: 0000000005020411, (reserved)

Debugging Details:
------------------


BUGCHECK_STR:  0x19_20

POOL_ADDRESS:  fffff8a00e352810 Paged pool

DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULT

PROCESS_NAME:  chrome.exe

CURRENT_IRQL:  0

ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) amd64fre

LAST_CONTROL_TRANSFER:  from fffff800019c2cbe to fffff8000188ce00

STACK_TEXT:  
fffff880`08f76788 fffff800`019c2cbe : 00000000`00000019 00000000`00000020 fffff8a0`0e352810 fffff8a0`0e352830 : nt!KeBugCheckEx
fffff880`08f76790 fffff880`058e23de : 00000000`00000001 fffff8a0`0e352820 00000000`66426753 00000000`00000001 : nt!ExFreePool+0xd8a
fffff880`08f76840 fffff880`058e7f29 : fffffa80`06e7a040 fffff880`059081e0 00000000`56658220 fffffa80`00b73ab0 : Sftplaywin7+0x173de
fffff880`08f768e0 fffff880`058cd3bd : fffffa80`056901c0 fffff880`059081e0 00000000`56658220 fffffa80`04d96060 : Sftplaywin7+0x1cf29
fffff880`08f76950 fffff800`01b9be4a : 00000000`00000002 00000000`00000038 00000000`00000001 fffffa80`0597ecf0 : Sftplaywin7+0x23bd
fffff880`08f76990 fffff800`01bb035c : fffffa80`0597ecf0 00000000`00000038 fffffa80`0597ecf0 fffff880`009c4180 : nt!IopSynchronousServiceTail+0xfa
fffff880`08f76a00 fffff800`01bb03f6 : fffff680`00329ec8 00000000`00000000 00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0xc49
fffff880`08f76b40 fffff800`0188c093 : ffffffff`ffffffff 0000007f`ffffffff 00000000`00000000 00000980`00000000 : nt!NtDeviceIoControlFile+0x56
fffff880`08f76bb0 00000000`74632e09 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`000cec08 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x74632e09


STACK_COMMAND:  kb

FOLLOWUP_IP: 
Sftplaywin7+173de
fffff880`058e23de 8bc7            mov     eax,edi

SYMBOL_STACK_INDEX:  2

SYMBOL_NAME:  Sftplaywin7+173de

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: Sftplaywin7

IMAGE_NAME:  Sftplaywin7.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  52143ac3

FAILURE_BUCKET_ID:  X64_0x19_20_Sftplaywin7+173de

BUCKET_ID:  X64_0x19_20_Sftplaywin7+173de

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:x64_0x19_20_sftplaywin7+173de

FAILURE_ID_HASH:  {aacf9a18-e952-e927-2033-e65247442daa}

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

launching locally installed chrome 63.x from inside an app-v 5 application is working fine in our environment

even if version 63.x seems to be using a lot more memory than 62.x

haroonayub@,
Could you please respond as per C#25?
Thanks..!

Hi 

Back in the office today. Will get back to you ASAP.

I have shared the following so you can access the dump file that is created.

https://drive.google.com/file/d/1CFmZg-B3yHbPC1jCoQfUw8atlptwxOZ2/view?usp=sharing

if someone can run a debugger against that ?

Thank you! 

Me and my colleagues will see if we can extract the reason for the fault from this dump and get back on this  bug with results.

+grt and scottmg

From the full memory dump one can see the stack trace goes into the installer trying to read a registry key,

STACK_TEXT:  
9555fa10 95f2b3fe 9c4c1918 00000000 9555fa60 nt!ExFreePoolWithTag+0x1b1
WARNING: Stack unwind information not available. Following frames may be wrong.
9555fa20 95f2778d 9c4c1918 8658c540 8707b3f0 Sftplaywin7+0x133fe
9555fa60 95f2bc5e 00000000 0028f318 00000001 Sftplaywin7+0xf78d
9555fa84 95f2c0be 8658c540 0000001c 0000001c Sftplaywin7+0x13c5e
9555faa0 95f19e13 56658220 8658c540 0000001c Sftplaywin7+0x140be
9555fadc 82843169 872569d0 857a3748 857a3748 Sftplaywin7+0x1e13
9555faf4 82a3b8cf 0000001c 857a3748 857a37b8 nt!IofCallDriver+0x63
9555fb14 82a3ec3e 872569d0 8707b3f0 00000000 nt!IopSynchronousServiceTail+0x1f8
9555fbd0 82a85c62 000000b8 857a3748 00000000 nt!IopXxxControlFile+0x830
9555fc04 82849e06 000000b8 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
9555fc04 778d6c74 000000b8 00000000 00000000 nt!KiSystemServicePostCall
0028f1b4 778d542c 759eab4d 000000b8 00000000 ntdll!KiFastSystemCallRet
0028f1b8 759eab4d 000000b8 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xc
0028f218 7656bbc5 000000b8 56658220 0028f2bc KERNELBASE!DeviceIoControl+0xf6
0028f244 69e1b34f 000000b8 56658220 0028f2bc kernel32!DeviceIoControlImplementation+0x80
0028f270 69e1bb66 56658220 0028f2bc 0000001c sftldr!IsProcessHooked+0x18b88
0028f2b0 69e1c19a 0028f2d8 00000000 08000004 sftldr!IsProcessHooked+0x1939f
0028f2e0 011c18eb 08000004 0028f318 00000001 sftldr!IsProcessHooked+0x199d3
0028f324 011c1969 08000004 011fb1c8 0028f34c setup!nt::QueryRegKeyValue+0x69 [c:\b\c\b\win_pgo\src\chrome_elf\nt_registry\nt_registry.cc @ 820] 
0028f350 011c19e0 08000004 011fb1c8 0028f3ec setup!nt::QueryRegValueSZ+0x28 [c:\b\c\b\win_pgo\src\chrome_elf\nt_registry\nt_registry.cc @ 886] 
0028f36c 01120478 00000001 00000200 004ef2b0 setup!nt::QueryRegValueSZ+0x37 [c:\b\c\b\win_pgo\src\chrome_elf\nt_registry\nt_registry.cc @ 909] 
0028f408 0111359e 7656c501 00000000 0028f434 setup!install_static::DetermineChannel+0xb2 [c:\b\c\b\win_pgo\src\chrome\install_static\install_util.cc @ 874] 
0028f484 01109e43 01215e20 00000000 01216100 setup!MakeInstallDetails+0xd2 [c:\b\c\b\win_pgo\src\chrome\installer\setup\setup_install_details.cc @ 100] 
0028fc8c 011c3b08 010f0000 00000000 002d18bc setup!wWinMain+0x20a [c:\b\c\b\win_pgo\src\chrome\installer\setup\setup_main.cc @ 1301] 
0028fcd8 7656ef8c 7ffd8000 0028fd24 778f367a setup!__scrt_common_main_seh+0xf6 [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 283] 
0028fce4 778f367a 7ffd8000 77b40ad5 00000000 kernel32!BaseThreadInitThunk+0xe
0028fd24 778f364d 011c3b80 7ffd8000 00000000 ntdll!__RtlUserThreadStart+0x70
0028fd3c 00000000 011c3b80 7ffd8000 00000000 ntdll!_RtlUserThreadStart+0x1b

Scott, Greg can this be due to an issue with the sftldr third party dll trying to operate inside the installer process?

Hi haroonayub@,

While we are investigating can you pleasetry to run App-V with the registry flag suggested in the second half of this article https://madvirtualizer.wordpress.com/tag/sftldr/ and upload the resultant log file. I am not 100% sure it will be of further help but any bit of info might be useful.

Thanks,
Julian

Hi Julian

Please see attached log file as requested.

Thanks

Haroon

Deleted: SFTLDR.LOG 654 KB

SFTLDR.LOG 654 KB View Download

pennymac: PTAL. looks like the nt_registry wrapper is making App-V 4 choke. Any ideas?

Another log file !

Deleted: SFTLDR.LOG 1.3 MB

SFTLDR.LOG 1.3 MB View Download

Hmm. nt_registry::QueryRegKeyValue changed between 62 and 63 in r506086. Did we break it? The code still looks technically correct to me (and it does the right thing when I step through it), so I think we may be tickling a bug in the App-V shims. The M62 code called NtQueryValueKey with nullptr, 0 for the info and length params, whereas the new code passes in a 1-byte buffer and 1 on the first call. Perhaps we should change to starting with size_needed = 0 and pass nullptr for value_info on the first time through the loop. This should revert back to the M62 calling pattern.

Do we have an in-house repro for this?

I have a CL out for review that may fix this. Could someone with a repro grab the installer I've placed in https://drive.google.com/open?id=1CLC8IBiubOF6iaV4nosV3Td6goL7vN6S and see if it results in a Chrome that will launch? Please uninstall it after testing, as it's entirely likely to be broken in other ways. Thanks.

We tested this version and it seems to fix the App-V 4.6 Issue !!!

Any idea when this could be generally available ???

We'll try to follow up with some info after the change is reviewed and lands on tip-of-tree. We'll merge it up the release branches as aggressively as we are able.

Oh, and a thousand thanks for the verification. :-)

Uninstall is not working for this version :-(

Can you provide a bit more detail? Do you see the "Uninstall Google Chrome" dialog"? What happens?

Just jumping into this.  Thanks for the fast action Greg!  

We can get a "fix" out, but we should also report the details/repro as a bug in the App-V shims.  This was a valid QueryRegKeyValue call.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f2d73e5016e9f212dded87e65ed1ae0d0da4e723

commit f2d73e5016e9f212dded87e65ed1ae0d0da4e723
Author: Greg Thompson <grt@chromium.org>
Date: Fri Jan 05 05:25:48 2018

Fix buffer handling in nt_registry query functions.

- NtQueryValueKey, NtQueryKey, and NtEnumerateKey may each return either
  STATUS_BUFFER_OVERFLOW or STATUS_BUFFER_TOO_SMALL to indicate that
  more memory is needed.
- App-V 4 causes an app crash when a one-byte buffer is passed to
  NtQueryValueKey. Attempt to work around this by always starting with
  sizeof(KEY_VALUE_FULL_INFORMATION) bytes.

BUG= 794695 
R=pennymac@chromium.org

Change-Id: I3b08e6c9790aee61f36482d950ceb70420fd4369
Reviewed-on: https://chromium-review.googlesource.com/850555
Commit-Queue: Penny MacNeil <pennymac@chromium.org>
Reviewed-by: Penny MacNeil <pennymac@chromium.org>
Cr-Commit-Position: refs/heads/master@{#527222}
[modify] https://crrev.com/f2d73e5016e9f212dded87e65ed1ae0d0da4e723/chrome_elf/nt_registry/nt_registry.cc

Thanks for the quick resolution Penny and Greg!

Re c45: I think MS is ware of the issue but because App-V 4.x is unsupported already they won't offer a fix for it.Provided the cost to fix this incompatibility on our side is not too high I think it is of our best interest to do so though given the rather large base of users still using it.

RE C43: Unable to reproduce. But the uninstall starts and then a message "File not found is displayed" If you are unable to provide a quick hint / fix It's not a big issue. We can re-install the machine. It might have something to do with Chrome enterprise being on the machine and then installing the version that resides in the %AppDataLocal% ???

Ah, okay. That sounds unrelated to the fix here, and may indeed be a result of using a developer component build on a machine that also has a release enterprise Chrome.

It looks like our fix will be in tomorrow's canary channel. If you could verify on Monday that Chrome canary works in your environment (https://www.google.com/chrome/browser/canary.html?platform=win64), then we'll merge it forward as quickly as possible. For extra assurance, it would be good to install the current canary and verify that it *does not* work. Then on Monday check to see if it works. Thanks for your help.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-63; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-63 label, otherwise remove Merge-TBD label. Thanks.

I'll request a merge once we have feedback from the change in canary. Thanks.

Thanks grt@ Can you please confirm how the results from Canary look? 

tested 65.0.3316.0 (x64) starting Chrome.exe from within a App-V Sequence and it works without the BSOD.

Thank you for the confirmation. Let's merge it on up.

This bug requires manual review: We are only 13 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Approving for merge for M64. Branch:3282
Rejecting merge for M63 (no respins planned)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/12e7c2cc2e5f8f8f2e0983a22356f57436b3e7a5

commit 12e7c2cc2e5f8f8f2e0983a22356f57436b3e7a5
Author: Greg Thompson <grt@chromium.org>
Date: Wed Jan 10 08:49:36 2018

Fix buffer handling in nt_registry query functions.

- NtQueryValueKey, NtQueryKey, and NtEnumerateKey may each return either
  STATUS_BUFFER_OVERFLOW or STATUS_BUFFER_TOO_SMALL to indicate that
  more memory is needed.
- App-V 4 causes an app crash when a one-byte buffer is passed to
  NtQueryValueKey. Attempt to work around this by always starting with
  sizeof(KEY_VALUE_FULL_INFORMATION) bytes.

BUG= 794695 
R=​pennymac@chromium.org

Change-Id: I3b08e6c9790aee61f36482d950ceb70420fd4369
Reviewed-on: https://chromium-review.googlesource.com/850555
Commit-Queue: Penny MacNeil <pennymac@chromium.org>
Reviewed-by: Penny MacNeil <pennymac@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#527222}(cherry picked from commit f2d73e5016e9f212dded87e65ed1ae0d0da4e723)
Reviewed-on: https://chromium-review.googlesource.com/859297
Reviewed-by: Greg Thompson <grt@chromium.org>
Cr-Commit-Position: refs/branch-heads/3282@{#477}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/12e7c2cc2e5f8f8f2e0983a22356f57436b3e7a5/chrome_elf/nt_registry/nt_registry.cc

Hi, When can we see this fix in the Stable Enterprise editions ?

The fix will be in the first release of Chrome 64. The estimated stable date for that release is Jan 23 (https://www.chromium.org/developers/calendar), so you should see it soon.

Hi. 64.0.3282.119 is now shipping on stable. Cheers!