There was a problem with WSL: Docker Stopped During an App Move

While moving ChatGPT to another drive through Windows Settings, Docker stopped with a WSL error. The logs recorded the entire drive being dismounted while the app storage location was being prepared. Restarting Docker alone restored the engine.

The WSL error displayed

After the ChatGPT move, Docker Desktop displayed the following error. Its details also showed that Docker’s WSL startup process had ended with exit code 135.

There was a problem with WSL
An error occurred while running a WSL command.
Please check your WSL configuration and try again.

exit status 135

Docker Desktop was version 4.95.0, and WSL was version 2.7.14.0. Docker’s data VHDX had already been on drive D before this migration, with a logical size of about 273GB. We did not move Docker’s data along with the ChatGPT app.

The long error details also included logs from startup the previous night. The initial warning about a missing componentsVersion.json predated the subsequent period in which Docker ran for about 11 hours. Instead of treating the first conspicuous warning as the direct cause, we reviewed events around the time Docker actually stopped.

This distinction changes the choice of remedy. Although the message said to check the WSL configuration, the central problem here was a loss of access to an active virtual disk, rather than an incorrect WSL setting. Before changing settings or re-registering WSL, we aligned the timestamps and examined Windows events.

The entire D drive was dismounted while the destination was being prepared

The decisive step was comparing NTFS, AppXDeploymentServer, and VHDMP logs alongside the ordinary System log. The table below shows saved event timestamps rounded to milliseconds in Japan Standard Time.

Drive D was dismounted before the ChatGPT package itself started moving. The entire drive was involved while Windows was preparing it for use as an app storage location. Even with the app being moved closed, Docker could be affected if its virtual disk on the same drive remained open.

The requester recorded by NTFS was svchost.exe. Matching the event’s process ID against the same process, which had been running since before the failure, and Windows service information identified StorSvc, or Storage Service. This was separate from the AppX process registering the app storage location; we did not treat the two processes as one.

About 3.3 seconds elapsed from the start of dismounting to completion of remounting. The interval from successful dismount to completion of remounting was about 0.17 seconds. We therefore cannot say that drive D was completely absent for 3.3 seconds. The problem was that even a short operation could break access to files in use and prevent apps from continuing afterward.

What 0xC000026E revealed

In Microsoft’s NTSTATUS definitions, 0xC000026E means STATUS_VOLUME_DISMOUNTED. It indicates that an operation was attempted on a dismounted volume. This value also appeared in the failed reads of Docker’s VHDX.

The WSL kernel records also showed virtual-storage READ failures, the device going offline, and containerd crashing with signal 7. The Windows virtual-disk records and the eventual WSL shutdown formed a consistent timeline.

Microsoft’s documentation on dismounting volumes explains that a dismount can be attempted even while a volume is in use, with unpredictable effects on processes using it. The behavior in this case is consistent with that general property. However, we did not capture a stack showing this particular API being called, so we have not established a specific internal Windows call path.

The event’s reason field said User request. We did not interpret that as proof that a person clicked “Eject USB.” Examining the requesting service and timeline connected it to processing while Windows prepared the app storage location.

The USB, PnP, and related logs we examined for the same period did not contain evidence supporting a physical disconnection and reconnection. The drive also reported Healthy during the investigation. This does not guarantee that the SSD is free of faults, but the direct failure path found here was Storage Service’s dismount followed by failed VHDX access.

The PackageVolume mechanism documented by Microsoft is a supported way to store apps. Even so, using a built-in move feature did not mean other apps using that drive could keep running without interruption.

Unity also had an I/O failure at the same time

A Unity project was on the same drive, and Unity Bug Reporter appeared. Application Error records showed Unity Data Store crashing at 13:20:47–49, before Docker was restarted. The exception was 0xC0000006, and the underlying I/O status was 0xC000026E.

Microsoft defines 0xC0000006 as STATUS_IN_PAGE_ERROR, meaning required data could not be brought into memory because of an I/O error. The underlying status contained the same dismount value as Docker’s failure. This supports the conclusion that Unity was affected by the same drive becoming unavailable.

However, the event’s filename field was empty, so we did not identify the specific file Unity failed to access. The appearance of Unity.dll in a later crash record alone did not establish a corrupted DLL or a need to reinstall.

We did not restart Unity immediately. We separately preserved 5 files, totaling about 8MB, including an existing scene backup, logs, and dumps. The scene backup was timestamped 08:31 that day; it does not prove that unsaved work from immediately before the crash was preserved. We did not overwrite the original project with the preserved files during this investigation.

This sequence also rules out an account in which restarting Docker first broke Unity. The first Unity Data Store crash occurred before Docker’s restart. Investigating the failure required checking event times in the logs, rather than relying only on the order in which screens appeared.

Restarting Docker alone restored the engine

After retaining enough logs locally to trace the cause and confirming that drive D was accessible again, we restarted only Docker Desktop, once. We used Docker’s official CLI. The following command affects active Docker work, so check which processes need saving or stopping before running it.

docker desktop restart --timeout 45

Docker’s official restart documentation describes --timeout as an option limiting how long the command waits. It does not mean recovery is guaranteed within 45 seconds. This invocation completed with exit code 0.

We then used docker version to check the Server response and obtained Engine 29.8.2. The WSL inventory also showed docker-desktop as Running again. The new backend started during the 13:27 minute.

The retrieved inventory contained 108 containers: 1 running, 106 exited, and 1 created. We did not start stopped containers in bulk. A responding engine is different from each project’s databases and services working as before, so functional checks of the required services were left to their respective owners.

Recovery did not involve a factory reset, data deletion, WSL unregistration, or reinstallation. We also did not shut down all of WSL, which would affect more than Docker, or upload a complete set of diagnostic data externally. The important point was not jumping straight from an error screen to an action that could lose stored data.

Logs that helped identify the cause

Looking only at the System log initially did not reveal the decisive dismount records. Their absence from System did not mean Windows had no record. Ordering the following logs by time connected the app move preparation with I/O failures in other apps.

For readers investigating the same symptom, noting the time of the action, destination drive, Docker virtual-disk location, and error text first helps narrow the scope. Check which log channels are available on the computer and start by reading existing records. In this follow-up investigation, we did not enable diagnostic settings or reproduce the operation that caused the failure.

This article does not publish the username, user SID, device serial numbers, credentials, or container environment variables. When sharing logs, extracting only the necessary times, error codes, and operation names also makes the cause easier to follow.

What to decide before moving to another drive

Our shortcoming was focusing on stopping and backing up ChatGPT without adequately addressing the effect on Docker and Unity already running on drive D in the pre-move instructions. For a similar task in future, we would identify what needs stopping at the drive level.

1. Identify everything using the destination. Check Docker and VM virtual disks, databases, editor projects, and other processes that keep files on drive D open.
2. Preserve unsaved work and data needed for recovery. Make active work recoverable, rather than only copying the app itself.
3. Choose a time when processes using the drive can be stopped. Include work in other chats and by other owners, and prevent new processes from starting during the move.
4. Use Windows’ supported move feature. Do not change ownership or permissions on WindowsApps or WpSystem and manually move only the folders.
5. Check the move and other apps separately. Verify the functions actually needed, covering app startup, saved items, the browser, the Docker engine, and required services in that order.

The logs confirmed that this was drive D’s first registration as an app storage location. However, that does not establish that the same failure can never happen again now that registration is complete. We did not repeatedly register or dismount the drive used for real work to test it; we retained the currently working configuration.

Moving an app to drive D also does not consolidate every related file there. In this case, the app itself and its main data went to drive D, while the active CLI and other components stayed on drive C. For the overall storage layout and sizes, see our ChatGPT and Codex drive-migration record.

A successful move does not mean other apps were unaffected

The ChatGPT app itself was successfully moved to drive D, and we checked browser operations and saved items afterward. At the same time, the entire D drive was dismounted while the destination was being prepared, causing failures in Docker and other apps using virtual disks on that drive. The successful move event alone did not establish that surrounding apps were unaffected.

The logs explain the direct failure path in this case. We have not established which internal Windows call branch requested the dismount or whether the same behavior occurs on other computers or Windows versions. The concrete precaution supported by this case is to stop active processes using drive D, as well as the app being moved, before starting.

Frequently asked questions

Will reinstalling WSL fix “There was a problem with WSL”?

The failure path here was lost access to a virtual disk. Restarting Docker alone restored the engine; we did not reinstall or unregister WSL. Checking logs from the time of the failure first is a better way to protect stored data.

Does this mean the SSD on drive D failed?

What we found was a direct record of Storage Service dismounting drive D. We found no records showing a physical disconnection at the same time. This case provides no basis for concluding that the SSD failed.

Should I avoid Windows’ built-in app move feature?

Moving a package to another volume is a supported Windows feature. Based on this experience, we would allow time to stop other apps using the same destination, back up data, and check operations, rather than leaving those apps running through the move.

If Docker starts, can I assume everything has recovered?

The engine responding is separate from the services and database contents in each container. We verified engine recovery and retrieved the inventory; functional checks for the required projects remain separate.