Internal error 36000 during Windows 11 + Ubuntu dual-boot deployment (GPT/UEFI)
search cancel

Internal error 36000 during Windows 11 + Ubuntu dual-boot deployment (GPT/UEFI)

book

Article ID: 453180

calendar_today

Updated On:

Products

Ghost Solution Suite

Issue/Introduction

This article covers a failure that occurs after Ghost has finished copying disk data during a Windows 11 and Ubuntu dual-boot deployment on a GPT/UEFI disk. The disk copy itself completes successfully. The failure happens in a separate step immediately afterward, while Ghost updates the Windows boot configuration on the newly restored partition.

This article applies to Ghost Solution Suite 3.3 deployments using Ghost64.exe to restore a single image containing both a Windows 11 partition and a Ubuntu partition on the same GPT disk. It does not apply to single-OS deployments or to MBR disks.

How it works


A dual-boot GPT/UEFI deployment involves two stages. First, Ghost copies the disk data sector-by-sector or file-by-file depending on the switches used, writing both the Windows and Ubuntu partitions to the destination disk. Second, once the copy reaches 100%, Ghost runs a post-copy step that mounts the restored Windows NTFS partition and updates its boot configuration, this is what keeps the Windows Boot Manager and GRUB entries on the EFI System Partition pointing at valid, current partitions after the disk layout has changed.

The failure covered in this article happens in the second stage, not the first. Ghost has to read the Master File Table (MFT) of the NTFS partition it just finished writing in order to locate and patch the boot configuration data. Reading fresh metadata immediately after a large write is one of the more fragile points in this sequence, and a dual-boot GPT/UEFI layout adds more boot-related structures for Ghost to work through than a single-OS deployment does. This is why the deployed disk remains intact and bootable even when the error appears — the data transfer already succeeded before this step started.

Symptoms

  • Ghost64.exe reaches 100% complete on the disk copy, with normal transfer speed and no errors during the copy phase.
  • Immediately after, the console or on-screen dialog references "Internal error 36000" and "An internal inconsistency has been detected."
  • The corresponding GHOSTERR.TXT entry for this case records: Error Number 36000, Message "A signal or windows exception occurred," with a processor exception and exception code 0xc0000005 (ACCESS_VIOLATION).

    • The GHOSTERR.TXT file has:

      Error Number: 36000
      Message: A signal or windows exception occurred

      Command line arguments: -CLONE,MODE=RESTORE,SRC=\\<servername>\express\Images\Windows\W11.gho,DST=1 -sure

      Processor exception
      Generated at C:\ghost\Ghost\src\Hal\HardExceptionHandlerWin32.cpp:314

      Thread #2120 Call Stack
      NTFSStreamServer::returnMFTHeader
      NTFSMFTRecord::detect
      NTFSStreamServer::getMFTRecordHandle
      NTFSAttributeList::loadAttributeRegistry
      NTFSAttributeRangeCollection::loadRegistry
      NTFSAttributeRangeCollection::detect
      NTFSStreamServer::detect
      NTFSFilesystem::initialiseStreamServer
      NTFSFilesystem::detect
      NTFSMountFacet::mount
      FilesystemMounter::mount
      FilesystemMounter::getFilesystem
      LfoFilesystemManager::makeFromPath
      WindowsBootConfig::mountfs
      WindowsBootConfig::openStream
      WindowsBootConfig::patchRecoveryConsole
      WindowsBootConfig::updateDisk
      WindowsBootConfig::update
      LocalUpdateWindowsConfig
      updateWindowsConfig
      updateWindowsDiskConfig
      CopyFileToDisk
      GhostClonerImpl::copy
      GhostClonerImpl::runMainScript
      sub_main
      main

      Call Stack
      M:\ - M:\Ghost\Ghost64.exe 12.0
      0xFFFFFFFF92BC796D

      Exception code: 0xc0000005 ACCESS_VIOLATION

  • The deployed machine boots normally afterward, with both the Windows 11 and Ubuntu entries present and functional.

Environment

GSS 3.3.13
Ghost64.exe 12.0.0.11809 (Aug 21 2025 build)
Primary OS: Windows 11 25H2
Secondary OS: Ubuntu 24.04 LTS (XFS)

Cause

The error occurs while Ghost64.exe is running its post-copy Windows boot configuration update on the NTFS partition, immediately after the disk data transfer finishes. It is not related to the data transfer itself, and it is not related to the Linux filesystem or distribution in use. Ubuntu 24.04 LTS with an XFS partition is a supported configuration for imaging in Ghost Solution Suite 3.3 RU11 and later.

GHOSTERR.TXT shows the crash occurring inside NTFS Master File Table parsing (NTFSMFTRecord::detect, NTFSAttributeRangeCollection::loadRegistry), called from the boot configuration update path (WindowsBootConfig::update, WindowsBootConfig::patchRecoveryConsole, WindowsBootConfig::mountfs). This identifies where Ghost fails.

Resolution

Before applying the workaround, rule out a previously known and already-resolved cause of the same error number.

  1. Retrieve GHOSTERR.TXT from the automation environment (see Resolution, step 0).
  2. Check the stack trace under the error.
  3. If the trace shows VolumeContainer::getVolumesCount, LfoDeviceCommand::StartDriveEnumeration, or getDrives, this matches a different, already-resolved cause of Internal error 36000 (volume enumeration failure, GSS 3.3 RU2, fixed in RU3). Confirm the environment is on RU3 or later — if not, upgrading is the fix, not the workaround below.
  4. If the trace instead runs through WindowsBootConfig::update / WindowsBootConfig::mountfs / NTFS MFT parsing, or the environment is already on RU3 or later, proceed to the workaround.

Resolution

The following are provided as suggestions. It is based on a documented case of a comparable Windows/Linux dual-boot deployment that succeeded using raw disk mode on both sides of the operation.

Option A — raw disk capture and restore (-IR -OR)

Retrieve GHOSTERR.TXT first regardless of which option is used (see step 0), to run the diagnosis path above and to have it available if escalating.

Step

Action

Why

0

Retrieve GHOSTERR.TXT from the automation environment: at the command prompt, run cd X:\ghost, then notepad GHOSTERR.TXT, then File > Save As to external storage or a network share. The file may instead be named Ghosterr.dmp, viewable with the Microsoft Debug utility.

Needed to run the diagnosis path above, and required either way if escalating per step 5.

1

Recapture the source image using the -IR and -OR switches. Add these to whichever process currently creates the image — manual Ghost64.exe command line or a GSS Console Create Image task.

-IR captures the disk as a full, raw, sector-by-sector copy, including unused space, rather than using Ghost's file-aware "smart" copy. -OR overrides certain internal space and integrity checks.

2

Deploy the recaptured image using the same two switches, for example: ghost64.exe -CLONE,MODE=RESTORE,SRC=<image path>,DST=1 -IR -OR -SURE

A raw image captured with -IR is not guaranteed to restore correctly unless the restore also runs in raw mode.

3

Plan for a longer deployment window and more storage for the image.

Raw disk mode copies every sector on the disk, not just the space in use — comparable in effect to the -IB switch — so both the image size and deployment time increase substantially.

4

After a successful deployment, run bcdedit /enum all on the deployed machine.

Confirms the Windows Boot Manager and GRUB/Ubuntu entries point to valid, current partitions.

5

If the error still occurs with -IR -OR, keep the case open and provide the resulting GHOSTERR.TXT.

Indicates the issue isn't limited to the standard smart-copy path, which is useful information for Engineering.

 

Option B — partition-level imaging

Rather than capturing the whole disk as one image, capture and restore each operating system's partition separately.

  1. Capture each partition as its own image. If each OS occupies a single partition, this means running Ghost twice on the source machine — once against the Windows partition, once against the Linux partition.
  2. Before deploying, partition the destination disk manually with the correct partition sizes and layout. A partition-level restore writes into an existing partition; it does not create the partition table.
  3. Deploy each image to its corresponding destination partition individually, specifying the correct destination partition for each restore.
  4. Configure the boot loader manually after both partitions are restored, since Ghost's automatic boot configuration patch does not run as part of a partition-level restore.

This approach is only straightforward when each operating system occupies a single partition. Layouts with multiple partitions per OS require capturing and restoring each partition individually and manually reconstructing the full boot configuration, which adds meaningful setup time and more opportunities for error.

Do not treat -NOTRIM, -NTEXACT, or -IB as a substitute for -IR -OR. Each of those switches changes a different part of the copy process and does not route around the boot configuration step.

Verification

  • Deployment completes without the internal error 36000 message.
  • bcdedit /enum all on the deployed machine shows valid entries for both the Windows Boot Manager and the GRUB/Ubuntu boot entry.
  • Both operating systems boot successfully from the deployed disk.
  • If the error recurs even with -IR -OR, this does not resolve the case, reach out to Broadcom Support with the new GHOSTERR.TXT per Resolution step 5.

 

NOTE: In one instance, recreating the image solved their issue without having to try any of the mentioned options above.

Additional Information

Alphabetical list of Ghost command line parameters 
Internal Error 36000 When Imaging Unformatted Drives
GPT/UEFI to MBR/Legacy Image Conversion Support - Ghost Solution Suite
Capturing an image using UEFI and restoring with Legacy BIOS fails to restore

Powered by Wolken Software