Failed to create Emergency Disk - 0x01CF001E000000C1

[admin]

Hi,

Following up on the C:\Program bug I reported earlier. After deleting the C:\Program file and the first issue was resolved, a new error appeared when creating the Emergency Disk:

"The system cannot find the path specified. (0x0782008500000003)"

The WinPE build itself completes successfully (100%), but the error occurs during post-processing.

**Root Cause:**
Hasleo scans ALL volumes looking for a \Recovery\ folder, including volumes that have NO drive letter assigned (only a mount point). In my case, I have a 5.5TB NTFS data volume mounted at C:\mnt\WR6T1\ with no drive letter. Hasleo scans this volume using its GUID directly, finds no \Recovery\ folder, and fails with path not found - even though WinRE is perfectly healthy on the correct partition.

Important note: Even after assigning a drive letter to that volume, the error persisted. This confirms the issue is not about the missing drive letter itself, but about Hasleo failing to handle volumes that do not contain a \Recovery\ folder gracefully.

Log entry from BackupService.log showing the issue:
CheckPeCrab.cpp 199 nRet=0x0782008500000003 \\?\Volume{00000015-09e0-3804-9bdc-d8012a000000}\\Recovery\*

System info:
- OS disk: Disk 2 (C
- WinRE confirmed enabled and working (reagentc /info shows correct location)
- Affected volume: separate 5.5TB NTFS data volume, no drive letter, mounted at C:\mnt\WR6T1\

**Workaround:** Uninstall and reinstall Hasleo Backup Suite resolves the issue.

**Suggested fix:** Hasleo should only scan the actual WinRE partition as reported by reagentc instead of brute-force scanning all volumes. If scanning all volumes is necessary, the code should gracefully skip volumes that do not contain a Recovery folder instead of returning a fatal error.

Hope this helps. Thanks.

reagentc is not always reliable. For example, when WinRE is disabled, it does not display the path, even though WinRE still exists on the system. Moreover, across different languages or versions of Windows, its output format may vary, making parsing difficult and hurting compatibility - and no one can guarantee that Microsoft won't change the output format in the future.

Unfortunately, Microsoft does not provide an API to directly obtain the WinRE path. Scanning all volumes to locate WinRE, while admittedly inelegant, is currently the most reliable way to find it.

Regarding the error "The system cannot find the path specified", we would greatly appreciate it if you could provide the log file.

Thanks.

[azmawee]

Hi,

Following up on the C:\Program bug I reported earlier. After deleting the C:\Program file and the first issue was resolved, a new error appeared when creating the Emergency Disk:

"The system cannot find the path specified. (0x0782008500000003)"

The WinPE build itself completes successfully (100%), but the error occurs during post-processing.

**Root Cause:**
Hasleo scans ALL volumes looking for a \Recovery\ folder, including volumes that have NO drive letter assigned (only a mount point). In my case, I have a 5.5TB NTFS data volume mounted at C:\mnt\WR6T1\ with no drive letter. Hasleo scans this volume using its GUID directly, finds no \Recovery\ folder, and fails with path not found - even though WinRE is perfectly healthy on the correct partition.

Important note: Even after assigning a drive letter to that volume, the error persisted. This confirms the issue is not about the missing drive letter itself, but about Hasleo failing to handle volumes that do not contain a \Recovery\ folder gracefully.

Log entry from BackupService.log showing the issue:
CheckPeCrab.cpp 199 nRet=0x0782008500000003 \\?\Volume{00000015-09e0-3804-9bdc-d8012a000000}\\Recovery\*

System info:
- OS disk: Disk 2 (C
- WinRE confirmed enabled and working (reagentc /info shows correct location)
- Affected volume: separate 5.5TB NTFS data volume, no drive letter, mounted at C:\mnt\WR6T1\

**Workaround:** Uninstall and reinstall Hasleo Backup Suite resolves the issue.

**Suggested fix:** Hasleo should only scan the actual WinRE partition as reported by reagentc instead of brute-force scanning all volumes. If scanning all volumes is necessary, the code should gracefully skip volumes that do not contain a Recovery folder instead of returning a fatal error.

Hope this helps. Thanks.

reagentc is not always reliable. For example, when WinRE is disabled, it does not display the path, even though WinRE still exists on the system. Moreover, across different languages or versions of Windows, its output format may vary, making parsing difficult and hurting compatibility - and no one can guarantee that Microsoft won't change the output format in the future.

Unfortunately, Microsoft does not provide an API to directly obtain the WinRE path. Scanning all volumes to locate WinRE, while admittedly inelegant, is currently the most reliable way to find it.

Regarding the error "The system cannot find the path specified", we would greatly appreciate it if you could provide the log file.

Thanks.

Thanks for the detailed explanation, that makes sense regarding reagentc's reliability and the lack of a direct Microsoft API.

That said, I think there may be a more robust approach than brute-force scanning every volume. The key insight is that reagentc itself is just a thin wrapper that reads two data sources, both of which you can read directly without parsing reagentc's text output:

1. ReAgent.xml - located at C:\Windows\System32\Recovery\ReAgent.xml (always on the OS volume, fixed path, language-independent). It contains:
  - WinreBCD: the BCD GUID for the WinRE boot entry
  - WinreLocation: path, offset, and the disk/partition guid where WinRE actually lives
  - InstallState: whether WinRE is enabled/staged/disabled

  This is structured XML, not localized text, so it does not have the parsing/compatibility problems that reagentc /info output has. When WinRE is disabled, InstallState reflects that and WinreLocation may point to the staging folder instead, so you can still make a correct decision.

2. BCD - the WinreBCD GUID from ReAgent.xml maps to a BCD entry whose 'device' element gives the partition. You can read this via the BCD WMI provider (root\WMI, BcdObject / BcdStore classes) which is a real, documented, stable API, no text parsing required.

So the chain is: read ReAgent.xml (fixed path) -> get WinreLocation guid/offset OR WinreBCD GUID -> resolve the exact partition. No need to touch unrelated data volumes at all.

If you still prefer the scan-all-volumes approach as a fallback, the actual bug here is simply that the scan returns a FATAL error when a volume has no \Recovery\ folder. A data volume legitimately having no Recovery folder is the normal case, not an error condition. Treating ERROR_PATH_NOT_FOUND on a per-volume scan as 'skip this volume and continue' rather than 'abort the whole operation' would fix it with a one-line change, regardless of the detection strategy.

I've attached the logs so you can see the full sequence. The relevant repeating entry is:

CheckPeCrab.cpp 199 nRet=0x0782008500000003 \\?\Volume{00000015-09e0-3804-9bdc-d8012a000000}\\Recovery\*

Volume {00000015-...} is my 5.5TB data volume, which correctly has no Recovery folder. WinRE on the real recovery partition (harddisk2 partition4) is healthy.

Hope this is useful. Thanks for looking into it.

[admin]

@azmawee,

Neither obtaining the WinRE path from ReAgent.xml nor from the BCD can guarantee 100% success. This is because the WIM files they point to may not exist at all, or ReAgent.xml and the BCD may contain no WinRE-related information at all. In my opinion, these methods can only serve as auxiliary approaches, while scanning all volumes is the safest and most reliable method.

We could not find the error record you mentioned earlier in the log:

CheckPeCrab.cpp 199 nRet=0x0782008500000003 \\?\Volume{00000015-09e0-3804-9bdc-d8012a000000}\\Recovery\*

In fact, the program's logic is: if the \Recovery\ folder is not found in one partition, it will proceed to try the next partition instead of reporting an error immediately. A programmer's logical reasoning is generally not that flawed - unless an unexpected situation occurs here, and a large part of a programmer's job is precisely handling such exceptions.

We only found the following error:

CopyFile.cpp 143 nRet=0x0782008500000003 C:\Program Files\Hasleo\Hasleo Backup Suite\bin\WinPE\Program Files\*.*

Regarding this error, please check whether the folder C:\Program Files\Hasleo\Hasleo Backup Suite\bin\WinPE\Program Files exists?


By the way, we have fixed the issue "Failed to create (start) process. (0x01CF001E000000C1)" in the following version:
https://www.easyuefi.com/backup-software...260603.exe

Please note that this is only a temporary build, but it includes the upcoming changes from the next release.

Thanks.

Best regards,

[azmawee]

@azmawee,

Neither obtaining the WinRE path from ReAgent.xml nor from the BCD can guarantee 100% success. This is because the WIM files they point to may not exist at all, or ReAgent.xml and the BCD may contain no WinRE-related information at all. In my opinion, these methods can only serve as auxiliary approaches, while scanning all volumes is the safest and most reliable method.

We could not find the error record you mentioned earlier in the log:

CheckPeCrab.cpp 199 nRet=0x0782008500000003 \\?\Volume{00000015-09e0-3804-9bdc-d8012a000000}\\Recovery\*

In fact, the program's logic is: if the \Recovery\ folder is not found in one partition, it will proceed to try the next partition instead of reporting an error immediately. A programmer's logical reasoning is generally not that flawed - unless an unexpected situation occurs here, and a large part of a programmer's job is precisely handling such exceptions.

We only found the following error:

CopyFile.cpp 143 nRet=0x0782008500000003 C:\Program Files\Hasleo\Hasleo Backup Suite\bin\WinPE\Program Files\*.*

Regarding this error, please check whether the folder C:\Program Files\Hasleo\Hasleo Backup Suite\bin\WinPE\Program Files exists?


By the way, we have fixed the issue "Failed to create (start) process. (0x01CF001E000000C1)" in the following version:
https://www.easyuefi.com/backup-software...260603.exe

Please note that this is only a temporary build, but it includes the upcoming changes from the next release.

Thanks.

Best regards,

Thanks for digging into the log. You're right, I was focusing on the wrong line. The fatal error was the CopyFile.cpp one pointing at \WinPE\Program Files\*.* inside Hasleo's own folder, not the volume scan.

This turned out to be corruption in Hasleo's internal WinPE folder structure, likely from all the manual WinPE folder deletion I did earlier while reproducing the first bug. A clean uninstall + reinstall restored the correct folder structure and everything works now.

Great to hear the C:\Program bug is fixed in the 260603 build. Thanks for the quick turnaround on both issues!