Photoshop crashes on PC wake

Photoshop crashes on resume from sleep when network connectivity is enabled

Summary

Photoshop consistently/regularly crashes when Windows 11 resumes from sleep, but only when network connectivity is enabled.

The crash occurs even before logging back into Windows in some cases. Photoshop is otherwise stable during normal use and does not crash during ordinary network activity.

I have traced a crash dump with WinDbg. The crash is a C++ exception originating in Photoshop's bundled msvcp140.dll, and the call stack shows Photoshop interacting with the Windows Network List Manager (netprofm) through COM/RPC during a network connectivity-change notification.

This strongly suggests a Photoshop bug in handling Windows network interface/connectivity notifications during or immediately after resume.

Reproduction

1. Start Windows 11 normally with Photoshop running.
2. Put the PC to sleep.
3. Wake the PC.
4. Photoshop crashes during/after the network interfaces transition back to their connected state.

The behaviour is strongly dependent on network connectivity:

• Both network adapters disabled: Photoshop does not crash on resume.
• Either network adapter enabled: Photoshop crashes on resume.
• This occurs with either Ethernet or Wi-Fi.
• Initially Wi-Fi appeared not to reproduce the problem, but this was because it was not actually connected. After entering the correct router password and establishing a real Wi-Fi connection, the crash returned.
• The crash can occur while Windows is still at the lock screen, before the user logs in.

I also tested blocking Photoshop.exe outbound traffic in Windows Defender Firewall. The crash still occurred. This indicates that actual network traffic from Photoshop is not required; the relevant trigger appears to be the Windows network/interface state notification itself.

Crash details

Photoshop:

27.10.0.26

Windows:

10.0.26200.x

Faulting module:

KERNELBASE.dll

Exception:

0xe06d7363

Example Event 1000:

Faulting application name: Photoshop.exe, version: 27.10.0.26
Faulting module name: KERNELBASE.dll, version: 10.0.26100.9444
Exception code: 0xe06d7363
Fault offset: 0x00000000000c41ca

0xe06d7363 is the MSVC C++ exception code.

WinDbg analysis

A full user-mode dump was captured using Windows Error Reporting LocalDumps.

The relevant exception stack is:

KERNELBASE!RaiseException
VCRUNTIME140!_CxxThrowException
msvcp140!std::_Throw_Cpp_error+0x46
Photoshop
Photoshop
Photoshop
...
rpcrt4!Invoke
rpcrt4!NdrStubCall2
combase!CStdStubBuffer_Invoke
...
netprofm!PublicNetworkListManager::GetConnectivity
Photoshop
...
netprofm!PublicNetworkListManager::GetNetworkConnections
netprofm!PublicNetworkListManager::GetNetworkConnectionFromInterfaceId
netprofm!PublicNetworkListManager::PrivateNetworkEventSync::FireNetworkConnectionConnectivityChangedEvent
netprofm!PublicNetworkListManager::PrivateNetworkEventSync::OnInterfacePropertyChange

The important point is that the exception originates in:

msvcp140!std::_Throw_Cpp_error

and msvcp140.dll is the copy bundled with Photoshop:

C:\Program Files\Adobe\Adobe Photoshop 2026\msvcp140.dll

Version:

14.42.34438.0

Disassembly of _Throw_Cpp_error shows that it is being called with argument 2. I decoded the corresponding internal MSVC STL error-table entry and it maps to the message:

"no such process"

The exception is therefore a std::system_error being explicitly thrown by the MSVC C++ runtime. The text "no such process" should not necessarily be interpreted literally as a process-launch failure; it is the message associated with the STL error-table entry selected by _Throw_Cpp_error(2).

Network List Manager evidence

The Windows netprofm!PublicNetworkListManager::GetConnectivity function was also disassembled.

It obtains the private Network List Manager interface and invokes an internal COM/vtable method to obtain the current network state, then converts that state to NLM connectivity information.

The stack shows this happening as part of:

PrivateNetworkEventSync::OnInterfacePropertyChange
    ↓
FireNetworkConnectionConnectivityChangedEvent
    ↓
GetNetworkConnectionFromInterfaceId
    ↓
GetNetworkConnections
    ↓
COM/RPC
    ↓
Photoshop
    ↓
GetConnectivity

There is consequently a re-entrant COM/RPC path between Windows Network List Manager and Photoshop at the point where Photoshop eventually throws the C++ exception.

Other troubleshooting

I initially suspected the GPU because disabling GPU compositing affected the frequency/behaviour, but the crash continued with GPU compositing disabled.

I also tested:

• Photoshop 26.11.6
• Photoshop 27.9.1.1
• Photoshop 27.10.0.26
• GPU compositing disabled
• OpenCL disabled
• Different display configurations
• NIC power-management settings
• Creative Cloud desktop application disabled
• Photoshop network traffic blocked by Windows Firewall

The crash has persisted across Photoshop versions and the GPU/OpenCL configuration changes.

The decisive test was disabling both network adapters: with networking disabled, Photoshop stops crashing on resume.

Hardware

• Intel Core i5-13600K
• 64 GB RAM
• NVIDIA RTX 3090
• Intel UHD 770 integrated graphics
• Three displays:
  • 3840×2160 144 Hz 10-bit display connected to RTX 3090
  • Two 2560×1600 120 Hz displays connected to Intel UHD 770

Current NVIDIA Studio driver is a recent 2026 driver. The problem has also occurred with an earlier NVIDIA driver, so I do not currently consider the NVIDIA driver the primary cause.

Current workaround

The only reliable workaround identified so far is to disable the network adapters before sleep, which is obviously impractical as a permanent solution.

Suspected cause

Based on both behavioural testing and the crash dump, my current suspicion is:

Photoshop is mishandling a Windows Network List Manager connectivity/interface-change notification generated during or immediately after system resume. A COM/RPC callback enters Photoshop, Photoshop queries Network List Manager connectivity again, and an internal Photoshop operation eventually calls std::_Throw_Cpp_error(2). The resulting std::system_error is not handled and terminates Photoshop.

The fact that disabling network adapters prevents the crash, while blocking Photoshop's network traffic does not, makes the Windows network-state notification path a much stronger candidate than ordinary network communication.

Please could this be investigated specifically as a Photoshop/Windows Network List Manager (netprofm) interaction during system resume/network interface state changes?

I can provide the full WinDbg crash dump and the complete Event Viewer/Reliability Monitor information if required.