I am experiencing several serious issues with Photoshop 27.10.0.26 on Windows 11. I use Photoshop, Adobe Camera Raw and Bridge professionally for architectural/interior photography, often working with large files and large batches of images.

I have been troubleshooting this extensively and have now been able to reproduce some of the problems with controlled A/B tests. I also captured two full-memory user-mode dumps of Photoshop during the same prolonged hang and inspected them with WinDbg.

I am reporting all the findings together because they appeared during the same general period after updating Adobe applications, although I cannot determine whether they have a single underlying cause or represent separate regressions.

SYSTEM CONFIGURATION

OS

• Windows 11 x64

• Build reported by WinDbg: 10.0.26100

Photoshop

• Adobe Photoshop 27.10.0.26

Adobe Camera Raw

• Camera Raw 18.6.0.2698

CPU

• Intel Core i7-9800X

• 8 cores / 16 logical processors

• 3.80 GHz base clock

Memory

• 96 GB DDR4 RAM

GPU

• NVIDIA GeForce RTX 4070

• 12 GB VRAM (Camera Raw reports approximately 11.5 GB available)

NVIDIA driver

• Driver reported by Camera Raw: 32.0.16.1692

Important timeline detail: some of the Photoshop/Camera Raw freezes started before this particular NVIDIA driver was installed, so this specific driver version cannot explain the original onset of all of the freezes. However, I cannot rule out a broader Adobe/NVIDIA interaction.

Monitor / color management

• BenQ SW2700 wide-gamut monitor

• Monitor operating in the calibrated Custom 1 mode

• Windows default monitor ICC profile: custom calibration profile 260226.icm

• Photoshop preserves embedded RGB profiles

• Test JPEG: embedded/assigned sRGB IEC61966-2.1

• Photoshop Color Settings: Europe Prepress configuration

• Proof Colors disabled during comparison

Storage

• System/application drive: Samsung 970 NVMe 1 TB

• Additional WD_BLACK SN770 NVMe 2 TB

• Several SATA HDD/SSD archive drives

• Photoshop scratch configured on SSD/NVMe storage

I have also run Windows system and memory diagnostics during troubleshooting. Windows Memory Diagnostic completed without reporting bad memory pages. SFC/DISM were run; SFC initially repaired Windows files and subsequently completed cleanly. A scan of the system volume did not report filesystem errors.

One older archive HDD has SMART warnings/pending sectors and is being replaced/backed up. However, the reproducible Camera Raw save freeze described below also occurred while saving to the system NVMe drive, and the Photoshop hang captured in the dumps does not appear to be blocked on that archive disk.

ISSUE 1: CAMERA RAW FREEZES DURING SAVE WHEN GPU OPEN/SAVE ACCELERATION IS ENABLED

This is the most reproducible A/B test I have performed.

Camera Raw processing itself can work normally. The freeze frequently appears during output/save.

To eliminate the destination disk as a variable, I used the same batch of images and saved to the internal C: NVMe SSD.

Test A — GPU acceleration for Open and Save ENABLED

Camera Raw Preferences > Performance:

• Graphics Processor: Custom

• GPU acceleration enabled

• Use GPU for Open and Save: enabled

Result:

Camera Raw froze while saving the batch. In one controlled repeat it froze on the second image.

Test B — same batch, same destination, GPU Open/Save DISABLED

I changed only:

Use GPU for Open and Save: disabled

Everything else remained the same.

Result:

Processing was noticeably slower, but the complete batch saved successfully without freezing.

Test C — GPU Open/Save enabled again

I re-enabled exactly the same GPU Open/Save option and repeated the same batch.

Result:

Camera Raw froze again, on the second image.

Therefore, on this machine I can reproduce a very strong correlation:

GPU Open/Save ON → freeze

GPU Open/Save OFF → same batch completes successfully

I am not claiming that this proves whether the root cause is Camera Raw itself, the NVIDIA driver, or an interaction between them. It does show that the GPU-accelerated Open/Save path is a reliable trigger on this system.

ISSUE 2: GPU-DEPENDENT COLOR DIFFERENCE BETWEEN PHOTOSHOP AND BRIDGE / CAMERA RAW

I have also encountered a significant display color inconsistency.

The same sRGB JPEG, viewed on the same calibrated monitor, can appear visibly more saturated/red/orange in Photoshop than in Bridge/Camera Raw.

This is not a subtle difference. Skin/wood/warm colors and overall saturation can be visibly different.

I verified the following:

• Same image file

• Same monitor

• Same Windows ICC profile

• Image profile is sRGB IEC61966-2.1

• Photoshop is preserving the embedded profile

• Proof Colors is disabled

• Ctrl+Y does not account for the difference

• No monitor mode change is being made between applications

I then performed another A/B test.

Photoshop GPU ENABLED

Photoshop and Bridge displayed visibly different color for the same JPEG.

Photoshop appeared considerably more saturated/warm.

Photoshop GPU DISABLED

I disabled:

Preferences > Performance > Use Graphics Processor

I completely restarted Photoshop and reopened the same JPEG.

Result:

Photoshop and Bridge then matched visually.

Re-enabling GPU rendering causes the discrepancy to return.

This suggests that at least this display discrepancy depends on Photoshop's GPU rendering path rather than on the embedded image profile or the monitor ICC configuration.

I am not claiming which rendering result is absolutely colorimetrically correct, only that Photoshop's display changes depending on whether its GPU path is enabled, while the image, ICC configuration and physical monitor remain unchanged.

This is particularly serious for professional photographic work because it can lead to incorrect color corrections made to compensate for a display difference that is not actually present in the file.

ISSUE 3: PHOTOSHOP CAN STILL HANG WITH GPU DISABLED

Initially I suspected that all of the freezes might have the same GPU-related cause.

However, Photoshop subsequently entered a prolonged hang even with Photoshop GPU acceleration disabled.

This indicates that there may be at least two problems:

1. A GPU-related issue affecting Camera Raw accelerated Open/Save and Photoshop color rendering.

2. A separate Photoshop hang, or a broader Photoshop 27.10 regression that is not dependent on GPU acceleration.

During this second type of hang, Windows Task Manager did not label Photoshop as "Not Responding."

Photoshop remained visually/functionally frozen, but Task Manager showed approximately:

• Photoshop memory usage: ~18.5 GB

• GPU: approximately 0%

• Disk activity: approximately 0.1 MB/s

• CPU: approximately 6%

Because this CPU has 16 logical processors, approximately 6.25% total CPU usage can correspond roughly to one logical processor being continuously occupied.

This observation led me to capture full memory dumps while Photoshop was still in the frozen state.

TWO FULL-MEMORY DUMPS CAPTURED DURING THE SAME HANG

I created two Windows user-mode full-memory dumps of Photoshop during the same prolonged hang, separated in time.

Each dump is approximately 20 GB.

WinDbg identifies the dump as:

User Mini Dump File with Full Memory : Only application data is available

The Photoshop process version reported in the dump is:

27.10.0.26

The process had been running for approximately two hours when the first dump was captured.

Because these were manually captured hang dumps rather than crash dumps, !analyze -v reports a breakpoint (0x80000003). I do not believe the breakpoint itself represents the original cause of the hang; it appears to be associated with dump capture/debugging.

WINDBG FINDING: MAIN PHOTOSHOP THREAD CONTINUES CONSUMING CPU DURING THE HANG

The most interesting finding came from comparing !runaway between the two dumps.

First dump

Main thread:

Thread 0:5aa0 — User Mode Time: 0:06:41.000

The next most CPU-active thread:

Thread 55:f7c — 0:04:18.828

Most other threads had accumulated only seconds or no CPU time.

Second dump, captured later during the same hang

Main thread:

Thread 0:5aa0 — User Mode Time: 0:21:44.671

Thread 55:

Thread 55:f7c — 0:04:41.906

Most other threads changed very little.

Therefore, while Photoshop remained unusable/frozen, the main thread accumulated approximately 15 additional minutes of user-mode CPU time between the two dumps.

This is consistent with Task Manager continuing to report approximately 6% total CPU usage.

It does not look like the main Photoshop thread was simply sleeping while waiting for disk I/O.

MAIN THREAD STACK — FIRST DUMP

In the first dump, thread 0 was captured in Photoshop code containing this general stack sequence:

Photoshop!OptycaChar::GetLevel
Photoshop!OptycaChar::GetLevel
Photoshop!OptycaImpl::SetClientEncoding
Photoshop!OptycaImpl::SetClientEncoding
Photoshop!OptycaImpl::SetClientEncoding
Photoshop!OptycaImpl::SetClientEncoding
Photoshop!OptycaImpl::SetClientEncoding
Photoshop!OptycaImpl::SetClientEncoding
Photoshop!OptycaImpl::SetClientEncoding
Photoshop!OptycaImpl::NormalizeInput
Photoshop!IWRChar::operator=
Photoshop!IWRFontContext::Dispose
Photoshop!IWRFontContext::Dispose
user32!...
Photoshop!OptycaImpl::NormalizeInput
Photoshop!IWRChar::operator=
Photoshop!OptycaImpl::NormalizeInput
Photoshop!WRFontContextComponent::Info
Photoshop!IWRChar::operator=
Photoshop!WRFontRec::SetName

MAIN THREAD STACK — SECOND DUMP

In the second dump, captured considerably later during the same hang, the instantaneous instruction was different but the thread was still executing inside essentially the same family of Photoshop routines:

win32u!NtGdiCombineRgn
gdi32!CombineRgn
Photoshop!OptycaChar::SetLevel
Photoshop!OptycaChar::SetLevel
Photoshop!OptycaChar::GetLevel
Photoshop!OptycaChar::GetLevel
Photoshop!OptycaChar::GetLevel
Photoshop!OptycaImpl::SetClientEncoding
Photoshop!OptycaImpl::SetClientEncoding
Photoshop!OptycaImpl::SetClientEncoding
Photoshop!OptycaImpl::SetClientEncoding
Photoshop!OptycaImpl::SetClientEncoding
Photoshop!OptycaImpl::SetClientEncoding
Photoshop!OptycaImpl::SetClientEncoding
Photoshop!OptycaImpl::NormalizeInput
Photoshop!IWRChar::operator=
Photoshop!IWRFontContext::Dispose
Photoshop!IWRFontContext::Dispose
user32!...
Photoshop!OptycaImpl::NormalizeInput
Photoshop!IWRChar::operator=
Photoshop!OptycaImpl::NormalizeInput
Photoshop!WRFontContextComponent::Info
Photoshop!IWRChar::operator=
Photoshop!WRFontRec::SetName

The exact top frame changed between captures, which is expected for an executing thread, but the broader stack remained remarkably similar.

Because Adobe's private Photoshop symbols are not available to me, I understand that the exported symbol names/offsets shown by WinDbg may not identify the exact internal functions. I therefore do not want to conclude that this is necessarily a font/text engine bug based only on names such as Optyca, IWRFontContext, or WRFontContext.

However, the important observation is that the main Photoshop thread continued accumulating CPU for many minutes while Photoshop remained unusable and remained in essentially the same region/family of Photoshop code in both independently captured dumps.

LOCK ANALYSIS

I also ran:

!locks

WinDbg reported:

Scanned 82 critical sections

It did not report an obvious contended critical section/deadlock.

This does not look like a simple classic critical-section deadlock from the information available to me.

SECOND-HIGHEST CPU THREAD

I also inspected thread 55 because it had accumulated the second-highest CPU time.

At the moment of the first dump it was waiting normally in a condition variable:

ntdll!NtWaitForAlertByThreadId
ntdll!RtlSleepConditionVariableSRW
KERNELBASE!SleepConditionVariableSRW
msvcp140!_Cnd_timedwait
dynamic_torqnative!...

Therefore thread 55 did not appear to be actively spinning at the time of capture.

NVIDIA / D3D THREADS IN THE DUMP

The process contains expected NVIDIA/D3D/OpenCL-related threads and modules, including:

• nvwgf2umx

• nvopencl64

• NvMessageBus

• D3D12 background threads

Several of these threads were in normal wait states at capture time and had accumulated essentially zero CPU time.

For that reason, I do not think the mere presence of NVIDIA modules in the dump proves that the prolonged Photoshop hang described above is a GPU-driver hang.

This is also consistent with the fact that this particular Photoshop hang occurred with Photoshop GPU acceleration disabled.

The GPU remains strongly implicated in the separate reproducible Camera Raw Open/Save freeze and Photoshop display-color discrepancy described earlier.

PREVIOUS FREEZE BEHAVIOR

I have experienced multiple freezes over the last several weeks.

The behavior has not always been identical.

In some incidents:

1. Photoshop or Camera Raw stops responding first.

2. Other Windows applications initially continue working.

3. Later other applications can also become unresponsive.

4. The mouse can continue moving for some time.

5. Ctrl+Alt+Del may stop responding.

6. Eventually the entire machine can become unresponsive and require a hard reset.

In other incidents, such as the hang for which I captured these dumps, Windows remained sufficiently responsive to use Task Manager and create full Photoshop process dumps.

Event Viewer after hard resets naturally contains Kernel-Power 41 / unexpected shutdown events, but I have not found a useful WHEA, display-driver or disk event immediately preceding the hangs.

The dumps described above are therefore the first direct snapshot I have obtained of Photoshop while the application itself was actively stuck.

WHY I SUSPECT A 27.10 REGRESSION

These issues became prominent around the recent Photoshop/Adobe update cycle.

I am currently running Photoshop 27.10.0.26.

I am planning a controlled rollback to Photoshop 27.9.1 while leaving the following unchanged:

• NVIDIA driver

• Windows installation

• GPU

• CPU/RAM

• monitor mode

• monitor ICC profile

• storage configuration

I will then repeat the same GPU/color and Camera Raw tests and continue using Photoshop normally for production work.

I will update this report with the results.

If Photoshop 27.9.1 operates normally with the same NVIDIA driver and hardware, particularly if:

1. Photoshop and Bridge match with GPU rendering enabled,

2. Camera Raw can save the same batch with GPU Open/Save enabled,

3. the prolonged Photoshop hangs no longer occur,

that would provide additional evidence of a regression introduced in the current Adobe application versions.

I do not want to change the NVIDIA driver simultaneously because that would introduce a second variable.

FULL DUMPS AVAILABLE TO ADOBE ENGINEERING

I have preserved both approximately 20 GB full-memory Photoshop dumps captured during the same hang.

I am intentionally not uploading full-memory dumps publicly, since process memory may contain private/sensitive data.

If an Adobe employee/engineer would like to inspect them, I can provide the dumps through an appropriate private Adobe upload channel.

I can also provide:

• complete ~* k thread-stack output

• !runaway output from both dumps

• !analyze -v

• additional WinDbg commands requested by engineering

• screenshots of Photoshop/Bridge color differences

• Camera Raw GPU settings

• screenshots/video of the freeze behavior

• exact reproduction files/batch if useful

QUESTIONS FOR ADOBE ENGINEERING

Could someone from the Photoshop/Camera Raw engineering team please investigate whether there are known regressions in Photoshop 27.10 / Camera Raw 18.6 involving:

1. GPU-accelerated Camera Raw Open/Save on NVIDIA RTX 40-series GPUs?

2. GPU-dependent display/color differences between Photoshop and Bridge/Camera Raw under the same ICC-managed environment?

3. A main-thread CPU loop/hang in Photoshop 27.10 involving the code region represented by the Optyca / IWR / WRFontContext symbols in the public WinDbg stack?

4. Any interaction between these issues introduced in the current release?

I would be happy to run specific diagnostic builds, WinDbg commands or controlled reproduction tests if requested.

This machine is used for professional photography production, so I have tried to change only one variable at a time and document the results rather than assuming that the GPU, driver, hardware or Photoshop itself is responsible.

Thank you.