Windows 8.1 problem

[TomaszNowak1]

Latest version 2020.5 doesn't work with latest Windows 8.1 x64 (Build 9600). All default installation steps followed, after restart and disabling driver signature requirements it doesn't start a debugger. VM is shown in GUI without PipeName and other following stats.

Windows 10 x64 works fine.

[4d61726b]

@TomaszNowak1 Can you tell me a little bit more about your environment?

1. Are you running VMware Workstation or VirtualBox?
2. What version of that product are you running?
3. What is your host OS?
4. Is this issue reproducible? If you close everything and try again, does it happen every time?

[TomaszNowak1]

Sure, it's VMware Workstation 14 PRO, ver. 14.1.1 build 7528167 Host is latest Win10 100% reproducible

Thanks Tomasz

[TomaszNowak1]

Hold on, I noticed it doesn't stop on system boot. But when I created vm snapshot (with VirtualKD installed) and restored that, I got a connection with WinDbg! Strange...

Tomasz

[TomaszNowak1]

One more comment: As I mention before it starts when running as restored snapshot but it blue screens on Patch Guard: `0: kd> !analyze -v Connected to Windows 8.1 9600 x64 target at (Wed Dec 16 13:02:21.980 2020 (UTC - 8:00)), ptr64 TRUE Loading Kernel Symbols ............................................................... ................................................................ ........................ Loading User Symbols

Loading unloaded module list ..........

---

• *
• Bugcheck Analysis *
• *

  ---

CRITICAL_STRUCTURE_CORRUPTION (109) This bugcheck is generated when the kernel detects that critical kernel code or data have been corrupted. There are generally three causes for a corruption: 1) A driver has inadvertently or deliberately modified critical kernel code or data. See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx 2) A developer attempted to set a normal kernel breakpoint using a kernel debugger that was not attached when the system was booted. Normal breakpoints, "bp", can only be set if the debugger is attached at boot time. Hardware breakpoints, "ba", can be set at any time. 3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data. Arguments: Arg1: a3a01f5a7134778c, Reserved Arg2: b3b72be0c3b34eff, Reserved Arg3: fffff800d5c7f458, Failure type dependent information Arg4: 0000000000000001, Type of corrupted region, can be 0 : A generic data region 1 : Modification of a function or .pdata 2 : A processor IDT 3 : A processor GDT 4 : Type 1 process list corruption 5 : Type 2 process list corruption 6 : Debug routine modification 7 : Critical MSR modification 8 : Object type 9 : A processor IVT a : Modification of a system service function b : A generic session data region c : Modification of a session function or .pdata d : Modification of an import table e : Modification of a session import table f : Ps Win32 callout modification 10 : Debug switch routine modification 11 : IRP allocator modification 12 : Driver call dispatcher modification 13 : IRP completion dispatcher modification 14 : IRP deallocator modification 15 : A processor control register 16 : Critical floating point control register modification 17 : Local APIC modification 18 : Kernel notification callout modification 19 : Loaded module list modification 1a : Type 3 process list corruption 1b : Type 4 process list corruption 1c : Driver object corruption 1d : Executive callback object modification 1e : Modification of module padding 1f : Modification of a protected process 20 : A generic data region 21 : A page hash mismatch 22 : A session page hash mismatch 23 : Load config directory modification 24 : Inverted function table modification 25 : Session configuration modification 26 : An extended processor control register 27 : Type 1 pool corruption 28 : Type 2 pool corruption 29 : Type 3 pool corruption 2a : Type 4 pool corruption 2b : Modification of a function or .pdata 2c : Image integrity corruption 2d : Processor misconfiguration 2e : Type 5 process list corruption 2f : Process shadow corruption 30 : Retpoline code page corruption 101 : General pool corruption 102 : Modification of win32k.sys

Debugging Details:

KEY_VALUES_STRING: 1

PROCESSES_ANALYSIS: 1

SERVICE_ANALYSIS: 1

STACKHASH_ANALYSIS: 1

TIMELINE_ANALYSIS: 1

DUMP_CLASS: 1

DUMP_QUALIFIER: 0

BUILD_VERSION_STRING: 9600.17415.amd64fre.winblue_r4.141028-1500

DUMP_TYPE: 0

BUGCHECK_P1: a3a01f5a7134778c

BUGCHECK_P2: b3b72be0c3b34eff

BUGCHECK_P3: fffff800d5c7f458

BUGCHECK_P4: 1

FAULTING_IP: CI!CiValidateImageHeader+0 fffff800`d5c7f458 55 push rbp

CPU_COUNT: 2

CPU_MHZ: 892

CPU_VENDOR: GenuineIntel

CPU_FAMILY: 6

CPU_MODEL: 55

CPU_STEPPING: 4

CPU_MICROCODE: 6,55,4,0 (F,M,S,R) SIG: 2006906'00000000 (cache) 2006906'00000000 (init)

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0x109

PROCESS_NAME: System

CURRENT_IRQL: 2

ANALYSIS_SESSION_HOST: TNOWA-8121D-SDG

ANALYSIS_SESSION_TIME: 12-16-2020 13:02:23.0090

ANALYSIS_VERSION: 10.0.18362.1 amd64fre

STACK_TEXT:
ffffd00166d10158 fffff800e02730ba : 0000000000000000 0000000000000000 ffffd00166d102c0 fffff800e00b806c : nt!DbgBreakPointWithStatus ffffd00166d10160 fffff800e02729cb : 0000000000000003 a3a01f5a7134778c fffff800e01ec980 0000000000000109 : nt!KiBugCheckDebugBreak+0x12 ffffd00166d101c0 fffff800e01deaa4 : 0000000000000000 0000000000000000 000000000000bdb6 ffffe001df6bc2a4 : nt!KeBugCheck2+0x8ab ffffd00166d108d0 0000000000000000 : 0000000000000109 a3a01f5a7134778c b3b72be0c3b34eff fffff800d5c7f458 : nt!KeBugCheckEx+0x104

THREAD_SHA1_HASH_MOD_FUNC: 82eefb3f9b4e2bd4e18906ed25bce3db9d12b20f

THREAD_SHA1_HASH_MOD_FUNC_OFFSET: f446ff2e8ea28083f878148faa77d436a171d905

THREAD_SHA1_HASH_MOD: d084f7dfa548ce4e51810e4fd5914176ebc66791

FOLLOWUP_IP: CI!CiValidateImageHeader+0 fffff800`d5c7f458 55 push rbp

FAULT_INSTR_CODE: 57565355

SYMBOL_NAME: CI!CiValidateImageHeader+0

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: CI

IMAGE_NAME: CI.dll

DEBUG_FLR_IMAGE_TIMESTAMP: 5308941c

STACK_COMMAND: .thread ; .cxr ; kb

BUCKET_ID_FUNC_OFFSET: 0

FAILURE_BUCKET_ID: 0x109_1_CI!CiValidateImageHeader

BUCKET_ID: 0x109_1_CI!CiValidateImageHeader

PRIMARY_PROBLEM_CLASS: 0x109_1_CI!CiValidateImageHeader

TARGET_TIME: 2020-12-16T20:56:15.000Z

OSBUILD: 9600

OSSERVICEPACK: 0

SERVICEPACK_NUMBER: 0

OS_REVISION: 0

SUITE_MASK: 784

PRODUCT_TYPE: 1

OSPLATFORM_TYPE: x64

OSNAME: Windows 8.1

OSEDITION: Windows 8.1 WinNt TerminalServer SingleUserTS Personal

OS_LOCALE:

USER_LCID: 0

OSBUILD_TIMESTAMP: 2014-10-28 17:38:48

BUILDDATESTAMP_STR: 141028-1500

BUILDLAB_STR: winblue_r4

BUILDOSVER_STR: 6.3.9600.17415.amd64fre.winblue_r4.141028-1500

ANALYSIS_SESSION_ELAPSED_TIME: 205f

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0x109_1_ci!civalidateimageheader

FAILURE_ID_HASH: {2be3c209-6836-e179-6d72-1fc872e92c51}

Followup: MachineOwner `

[4d61726b]

I have a few comments and questions regarding this...

Since you have a license for VMware Workstation 14 Pro, would it be possible to update to the latest version (14.1.8)? You mentioned that you are running the latest Windows 10 on your host and I know there are some stability issues with the version that you are running and later versions of Windows 10. When I installed 14.1.1 on a 20H2 host, I have many problems, including a consistent BSOD (on my host) when trying to copy files into the VM. This is before I even ran VirtualKD-Redux.

Stability issues aside, I was not able to reproduce the issue. Everything seems to work with a Windows 8.1 x64 guest VM. Have you installed any patches in that VM or done anything to it?

The first issue seems to be related to not being able to find or open the VMX process for the Windows 8.1 x64 VM. The VirtualKD-Redux monitor being able to communicate on that pipe all happens on the host and is guest OS agnostic. All that can occur before you even boot into Windows. I am curious what is happening there and wonder if something is interfering with that process on the host machine or if there is something specific about the configuration of that VM that is tripping up the monitor. For the purpose of troubleshooting:

1. Shutdown the Windows 8.1 VM.
2. Reboot your host box. This ensures that there are no lingering VMX processes and gets us into a clean state.
3. Start up VMware Workstation.
4. Start the Windows 8.1 VM but hit F2 at the VMware logo. This should take you to the BIOS.
5. Start vmmon64.exe. It should find the VM and you should now see a pipe in the GUI. If it doesn't, is there any output? Would you be able to take a screenshot of the window so I can see what you're seeing?

The second issue you mentioned is the BSOD in the guest which is very strange. I was also not able to reproduce that either but it seems to be Code Integrity / Patch Guard tripping up on a module. Are you comfortable with figuring out which module CiValidateImageHeader is faulting on in the debugger? I also don't mind looking at the crash dump if that's something you'd be willing to attach. I have a few follow up questions and some ideas but I'm curious if the module that CI is faulting on is the VirtualKD-Redux driver.

[TomaszNowak1]

Looks like you're right and VMware 14 Pro 14.1.1 is not the best workstation (I have many other problems with my host OS related to VMware). Let me update it and check it again..

[TomaszNowak1]

OK, after upgrading VMware to 15.5.0 I don't see any problems or patch guard issues anymore. Because I don't have previous 14.1.1 installed and it was failing release of VMware I think you can close this topic.

Thanks for help!

PS. Thank you for your work!