locked
App V 4.6 - Google Chrome 63.0.3239.84 (32bit) - BSOD - BAD POOL HEADER! RRS feed

  • Question

  • Hi

    I have also posted the below question on the chrome admin forum , and they have a raised bug ticket for it.

    Has any tried running the recent release of stable chrome version 63.0.3239.84 (32bit) through app v sequencer. (4.6 - 4.6.24020). Within a minute or two of running the MSI, the VM (win 7 - 32bit on HyperV) crashed with BSOD - BAD POOL HEADER.

    I have pasted in the debug log below. 

    (

    Probably caused by : Sftplaywin7.sys ( Sftplaywin7+133fe )

    )

    Can anyone else confirm this behavior.

    Thank you.

    Microsoft (R) Windows Debugger Version 10.0.17030.1002 AMD64
    Copyright (c) Microsoft Corporation. All rights reserved.
    
    
    Loading Dump File [U:\xxxxxx1.dmp]
    Mini Kernel Dump File: Only registers and stack trace are available
    
    Symbol search path is: srv*
    Executable search path is: 
    Windows 7 Kernel Version 7601 (Service Pack 1) UP Free x86 compatible
    Product: WinNt, suite: TerminalServer SingleUserTS
    Built by: 7601.23864.x86fre.win7sp1_ldr.170707-0600
    Machine Name:
    Kernel base = 0x82806000 PsLoadedModuleList = 0x82952e30
    Debug session time: Thu Dec 14 12:27:37.530 2017 (UTC + 0:00)
    System Uptime: 0 days 1:17:11.406
    Loading Kernel Symbols
    ...............................................................
    ................................................................
    ...........
    Loading User Symbols
    Loading unloaded module list
    .......
    Unable to load image \SystemRoot\system32\DRIVERS\Sftplaywin7.sys, Win32 error 0n2
    *** WARNING: Unable to verify timestamp for Sftplaywin7.sys
    *** ERROR: Module load completed but symbols could not be loaded for Sftplaywin7.sys
    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************
    
    Use !analyze -v to get detailed debugging information.
    
    BugCheck 19, {20, 976bb930, 976bb940, a020406}
    
    Probably caused by : Sftplaywin7.sys ( Sftplaywin7+133fe )
    
    Followup:     MachineOwner
    ---------
    
    eax=82941090 ebx=00000000 ecx=00000059 edx=00000000 esi=82933e20 edi=00000000
    eip=82929c6b esp=9fae39a0 ebp=9fae3a10 iopl=0         nv up ei pl nz na pe nc
    cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00000206
    nt!ExFreePoolWithTag+0x1b1:
    82929c6b cc              int     3
    kd> !analyze -v
    *******************************************************************************
    *                                                                             *
    *                        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: 00000020, a pool block header size is corrupt.
    Arg2: 976bb930, The pool entry we were looking for within the page.
    Arg3: 976bb940, The next pool entry.
    Arg4: 0a020406, (reserved)
    
    Debugging Details:
    ------------------
    
    
    DUMP_CLASS: 1
    
    DUMP_QUALIFIER: 400
    
    BUILD_VERSION_STRING:  7601.23864.x86fre.win7sp1_ldr.170707-0600
    
    SYSTEM_MANUFACTURER:  Microsoft Corporation
    
    VIRTUAL_MACHINE:  HyperV
    
    SYSTEM_PRODUCT_NAME:  Virtual Machine
    
    SYSTEM_VERSION:  7.0
    
    BIOS_VENDOR:  American Megatrends Inc.
    
    BIOS_VERSION:  090006 
    
    BIOS_DATE:  01/06/2017
    
    BASEBOARD_MANUFACTURER:  Microsoft Corporation
    
    BASEBOARD_PRODUCT:  Virtual Machine
    
    BASEBOARD_VERSION:  7.0
    
    DUMP_TYPE:  2
    
    BUGCHECK_P1: 20
    
    BUGCHECK_P2: ffffffff976bb930
    
    BUGCHECK_P3: ffffffff976bb940
    
    BUGCHECK_P4: a020406
    
    BUGCHECK_STR:  0x19_20
    
    POOL_ADDRESS: GetPointerFromAddress: unable to read from 82973850
    Unable to get MmSystemRangeStart
    GetUlongPtrFromAddress: unable to read from 82973208
    GetUlongPtrFromAddress: unable to read from 829736ec
    Unable to get NonPagedPoolStart
    Unable to get PagedPoolStart
     976bb930 
    
    CPU_COUNT: 1
    
    CPU_MHZ: a20
    
    CPU_VENDOR:  GenuineIntel
    
    CPU_FAMILY: 6
    
    CPU_MODEL: 4e
    
    CPU_STEPPING: 3
    
    CPU_MICROCODE: 6,4e,3,0 (F,M,S,R)  SIG: FFFFFFFF'00000000 (cache) FFFFFFFF'00000000 (init)
    
    CUSTOMER_CRASH_COUNT:  1
    
    DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULT
    
    PROCESS_NAME:  setup.exe
    
    CURRENT_IRQL:  0
    
    ANALYSIS_SESSION_HOST:  TCO00190L
    
    ANALYSIS_SESSION_TIME:  12-14-2017 13:45:21.0025
    
    ANALYSIS_VERSION: 10.0.17030.1002 amd64fre
    
    LAST_CONTROL_TRANSFER:  from 96ad93fe to 82929c6b
    
    STACK_TEXT:  
    9fae3a10 96ad93fe 976bb938 00000000 9fae3a60 nt!ExFreePoolWithTag+0x1b1
    WARNING: Stack unwind information not available. Following frames may be wrong.
    9fae3a20 96ad578d 976bb938 867bd280 87144da8 Sftplaywin7+0x133fe
    9fae3a60 96ad9c5e 00000000 0016ee08 00000001 Sftplaywin7+0xf78d
    9fae3a84 96ada0be 867bd280 0000001c 0000001c Sftplaywin7+0x13c5e
    9fae3aa0 96ac7e13 56658220 867bd280 0000001c Sftplaywin7+0x140be
    9fae3adc 8283d169 869089a8 87194570 87194570 Sftplaywin7+0x1e13
    9fae3af4 82a358cf 0000001c 87194570 871945e0 nt!IofCallDriver+0x63
    9fae3b14 82a38c3e 869089a8 87144da8 00000000 nt!IopSynchronousServiceTail+0x1f8
    9fae3bd0 82a7fc62 000000b8 87194570 00000000 nt!IopXxxControlFile+0x830
    9fae3c04 82843e06 000000b8 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
    9fae3c04 76e36c74 000000b8 00000000 00000000 nt!KiSystemServicePostCall
    0016ed08 00000000 00000000 00000000 00000000 0x76e36c74
    
    
    THREAD_SHA1_HASH_MOD_FUNC:  0c07424e5b114a0fdbf5537429de301d6bacfc03
    
    THREAD_SHA1_HASH_MOD_FUNC_OFFSET:  a4a850a7eea9aef8a0bb86729c0b4199797e428f
    
    THREAD_SHA1_HASH_MOD:  cc3a71088ec7f0dfbf992f7410d75c7fd1b26db1
    
    FOLLOWUP_IP: 
    Sftplaywin7+133fe
    96ad93fe ??              ???
    
    SYMBOL_STACK_INDEX:  1
    
    SYMBOL_NAME:  Sftplaywin7+133fe
    
    FOLLOWUP_NAME:  MachineOwner
    
    MODULE_NAME: Sftplaywin7
    
    IMAGE_NAME:  Sftplaywin7.sys
    
    DEBUG_FLR_IMAGE_TIMESTAMP:  503dfebb
    
    STACK_COMMAND:  .thread ; .cxr ; kb
    
    FAILURE_BUCKET_ID:  0x19_20_Sftplaywin7+133fe
    
    BUCKET_ID:  0x19_20_Sftplaywin7+133fe
    
    PRIMARY_PROBLEM_CLASS:  0x19_20_Sftplaywin7+133fe
    
    TARGET_TIME:  2017-12-14T12:27:37.000Z
    
    OSBUILD:  7601
    
    OSSERVICEPACK:  1000
    
    SERVICEPACK_NUMBER: 0
    
    OS_REVISION: 0
    
    SUITE_MASK:  272
    
    PRODUCT_TYPE:  1
    
    OSPLATFORM_TYPE:  x86
    
    OSNAME:  Windows 7
    
    OSEDITION:  Windows 7 WinNt (Service Pack 1) TerminalServer SingleUserTS
    
    OS_LOCALE:  
    
    USER_LCID:  0
    
    OSBUILD_TIMESTAMP:  2017-07-07 15:49:26
    
    BUILDDATESTAMP_STR:  170707-0600
    
    BUILDLAB_STR:  win7sp1_ldr
    
    BUILDOSVER_STR:  6.1.7601.23864.x86fre.win7sp1_ldr.170707-0600
    
    ANALYSIS_SESSION_ELAPSED_TIME:  384
    
    ANALYSIS_SOURCE:  KM
    
    FAILURE_ID_HASH_STRING:  km:0x19_20_sftplaywin7+133fe
    
    FAILURE_ID_HASH:  {7d472b94-7935-84a0-a45d-daa5d5c37ce7}
    
    Followup:     MachineOwner
    ---------
    

    Thursday, December 14, 2017 2:51 PM

All replies

  • Hi 

    we came across the exact same situation in our organisation. Raised a call with Microsoft. FYI here is the reply:

    Hello Ian,

    We took a look at the dump -  and as you reported, it goes with the two Packages so we has a Workaround at the moment.

    The Dump shows that indeed the SFTPLAY seem to get confused and overwrites beyond his own allocations:

    00 fffff880`35479088 fffff800`0230470e nt!KeBugCheckEx

    01 fffff880`35479090 fffff800`02285f2e nt!MmAccessFault+0x6fa6e

    02 fffff880`354791f0 fffff880`341cd738 nt!KiPageFault+0x16e

    03 fffff880`35479380 fffff880`341cd95d Sftplaywin7!VRFillValueClass_Unguarded+0x170

    04 fffff880`354793b0 fffff880`341beb33 Sftplaywin7!VRRegQueryValue+0x95

    05 fffff880`354793e0 fffff880`341ae7e1 Sftplaywin7!VRegQueryValue+0x22f

    06 fffff880`354794a0 fffff880`341beb9c Sftplaywin7!OSRegQueryValue+0x45

    07 fffff880`35479510 fffff880`341b1619 Sftplaywin7!VRegQueryValue+0x298

    08 fffff880`354795d0 fffff880`341b332e Sftplaywin7!VirtualizeQueryValueKey+0x99

    09 fffff880`354796a0 fffff880`341b8f41 Sftplaywin7!ViNtQueryValueKey+0x142

    0a fffff880`35479740 fffff880`3419e3d5 Sftplaywin7!vi_dispatch_virtual_request+0x375

    0b fffff880`354797b0 fffff800`02736880 Sftplaywin7!SWPlayDispatch+0x89

    0c fffff880`354797f0 fffff800`02596e4a nt!IovCallDriver+0xa0

    0d fffff880`35479850 fffff800`025ab35c nt!IopSynchronousServiceTail+0xfa

    0e fffff880`354798c0 fffff800`025ab3f6 nt!IopXxxControlFile+0xc49

    0f fffff880`35479a00 fffff800`02287093 nt!NtDeviceIoControlFile+0x56

    10 fffff880`35479a70 00000000`77a1bdaa nt!KiSystemServiceCopyEnd+0x13

    11 00000000`003eee18 00000000`00000000 0x77a1bdaa

    Explanation of the Bugcheck:

    DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION (d6)

    N bytes of memory was allocated and more than N bytes are being referenced.

    This cannot be protected by try-except.

    When possible, the guilty driver's name (Unicode string) is printed on

    the bugcheck screen and saved in KiBugCheckDriver.

    Because App-V 4 is already in extended support this will not get fixed… so we would recommend to sequence the Application on App-V 5 and here the issue should not happen.

    Please let me know if you have further questions or open topics on this.

    Thank you,

    Long story short - use APPV5 - not much good for us I'm afraid. Hope that helps.

      

    Friday, December 15, 2017 9:09 AM
  • Not trying to pile on but remaining on App-V 4.x is a dead end, extending your time now by ignoring that it's in Extended Support will just hurt more later. I feel for you because we said the same thing two years ago but now it's just a distant memory. There's no support for 4.6 on Windows 10 (despite it functioning) and Windows 7 has two years on it's self-destruct sequence as well...

    Jack

    Friday, December 15, 2017 9:18 AM