3D Slicer Freezes When Enabling Markups ROI Interaction Handles

Support
1

Problem report for 3D Slicer 5.12.3 win-amd64: [please describe expected and actual behavior]

Dear 3D Slicer Team,

I would greatly appreciate your help with a persistent and highly reproducible 3D rendering/freezing issue that I have been unable to resolve despite extensive troubleshooting.

I am an orthopedic surgeon and use 3D Slicer extensively for surgical planning and several custom scripted modules. The problem initially appeared around the time I attempted to move from Slicer 5.10 to Slicer 5.12.3. Importantly, the same computer had been running Slicer and my workflow without any problem for approximately one month before this occurred.

After many tests, the issue now appears to be much more specific than a general GPU, OpenGL, Volume Rendering, or extension problem. The most reproducible trigger we have identified is the 3D interaction handles of a Markups ROI, particularly in a scene in which Volume Rendering is active.

System

  • Laptop: ASUS ProArt PX13

  • Model: HN7306EAC

  • Operating system: Windows 11

  • GPU: AMD Radeon™ 8060S Graphics

  • Slicer versions tested:

    • 5.10

    • 5.12.3

  • The problem occurs even on a completely clean Slicer installation with no custom extensions loaded.

Current OpenGL report from Slicer:

OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: AMD Radeon(TM) 8060S Graphics
OpenGL version string: 3.2.0 Core Profile Context 26.7.1.260716

Current AMD display driver:

Driver version: 32.0.31035.1003
AMD Adrenalin: 26.7.1
Driver date: 24 July 2026

The original ASUS/OEM driver was:

32.0.22032.6002
15 December 2025

The problem occurred with both drivers.

Important timeline

The same laptop initially ran Slicer 5.10 normally for approximately one month.

The problem appeared around the time I attempted to install/use Slicer 5.12.3.

After the problem began:

  • I returned to Slicer 5.10.

  • The problem remained.

  • I completely removed Slicer.

  • Slicer user configuration folders were removed.

  • Registry remnants related to Slicer were removed.

  • Slicer 5.10 and 5.12.3 were both tested independently.

  • Eventually, Windows itself was completely reset/reinstalled.

  • Slicer 5.12.3 was then installed again as a clean installation with no extensions.

  • The problem still occurred immediately.

Therefore, this no longer appears to be caused by a corrupted Slicer installation, a custom extension, or a persistent Slicer preference.

I also tested the same Slicer 5.12.3 installation and my custom modules on another, less powerful computer, and they work normally there.

Main clinical/workflow symptom

A CT can be loaded and Volume Rendering can initially be displayed normally.

However, when certain 3D objects or interaction mechanisms are introduced, Slicer freezes completely and may subsequently terminate.

One particularly reproducible example is:

Volume Rendering → create/display a Markups ROI → Slicer freezes.

Sometimes the ROI outline becomes visible first and then the application freezes.

The same behavior occurs independently of my custom modules.

Event Viewer

During one Slicer 5.12.3 crash, Windows Event Viewer reported:

Faulting application:
SlicerApp-real.exe

Faulting module:
python312.dll

Exception code:
0xc0000005

There were also Application Hang / Event 1002 entries.

I realize that python312.dll being reported does not necessarily mean that Python itself is responsible, because the crash may occur in native VTK/OpenGL code invoked from Python.

OpenGL profile tests

The application was launched using:

set SLICER_OPENGL_PROFILE=core

and separately:

set SLICER_OPENGL_PROFILE=no

The problem remained in both cases.

I also tried:

set VTK_USE_LEGACY_DEPTH_PEELING=1

The problem remained.

Depth peeling investigation

Inspection of the renderers initially showed:

Renderer 0 | Layer: 0 | DepthPeeling: 1 | DepthPeelingForVolumes: True
Renderer 1 | Layer: 2 | DepthPeeling: 0 | DepthPeelingForVolumes: False
Renderer 2 | Layer: 1 | DepthPeeling: 0 | DepthPeelingForVolumes: False
Renderer 3 | Layer: 1 | DepthPeeling: 0 | DepthPeelingForVolumes: False
Renderer 4 | Layer: 1 | DepthPeeling: 1 | DepthPeelingForVolumes: False
Renderer 5 | Layer: 1 | DepthPeeling: 1 | DepthPeelingForVolumes: False

I then explicitly disabled both modes on all renderers:

rw = slicer.app.layoutManager().threeDWidget(0).threeDView().renderWindow()

renderers = rw.GetRenderers()
renderers.InitTraversal()

for i in range(renderers.GetNumberOfItems()):
    r = renderers.GetNextItem()
    r.SetUseDepthPeeling(False)
    r.SetUseDepthPeelingForVolumes(False)

rw.Render()

The resulting state was:

Renderer 0 | DepthPeeling: 0 | DepthPeelingForVolumes: False
Renderer 1 | DepthPeeling: 0 | DepthPeelingForVolumes: False
Renderer 2 | DepthPeeling: 0 | DepthPeelingForVolumes: False
Renderer 3 | DepthPeeling: 0 | DepthPeelingForVolumes: False
Renderer 4 | DepthPeeling: 0 | DepthPeelingForVolumes: False
Renderer 5 | DepthPeeling: 0 | DepthPeelingForVolumes: False

Even in this state, a normally created ROI could appear briefly and then Slicer would freeze.

Therefore, depth peeling alone does not appear to explain the problem.

Mesa / llvmpipe test

This was one of the most important tests.

I used Mesa software OpenGL with:

set GALLIUM_DRIVER=llvmpipe
set MESA_GL_VERSION_OVERRIDE=3.3COMPAT

Under llvmpipe:

the ROI worked and Slicer did not freeze.

Performance was extremely slow, as expected from CPU software rendering, but the problematic functionality worked.

I also attempted the Mesa D3D12 backend, but Slicer did not start with that configuration.

This suggests that the hardware-accelerated/native graphics path is involved, although the subsequent tests below indicate that native AMD OpenGL itself is capable of rendering the relevant VTK primitives.

Basic VTK transparency test

A completely independent VTK render window was created from the Slicer Python Interactor.

An opaque sphere rendered successfully.

The same sphere with:

actor.GetProperty().SetOpacity(0.25)

also rendered successfully.

The script reached:

1 - OPAQUE RENDER BASLIYOR
2 - OPAQUE RENDER TAMAM
3 - TRANSPARENT RENDER BASLIYOR
4 - TRANSPARENT RENDER TAMAM

Therefore:

native AMD OpenGL + VTK translucent polydata works.

Independent VTK Volume Rendering + translucent actor test

I then created a separate vtkRenderWindow containing:

  • vtkGPUVolumeRayCastMapper

  • a synthetic volume

  • a translucent vtkSphereSource actor

Both were rendered simultaneously.

The test successfully reached:

1 - SADECE VOLUME BASLIYOR
2 - SADECE VOLUME TAMAM
3 - VOLUME + TRANSPARENT OBJE BASLIYOR
4 - VOLUME + TRANSPARENT OBJE TAMAM

Therefore:

native AMD OpenGL + VTK GPU Volume Rendering + translucent polydata in the same renderer also works.

This seems important because it argues against a general AMD OpenGL transparency or VTK GPU volume-rendering failure.

Test inside Slicer’s actual 3D renderer

With Volume Rendering active, I inserted a simple vtkCubeSource wireframe actor directly into Slicer’s existing 3D renderer:

import vtk, slicer

view = slicer.app.layoutManager().threeDWidget(0).threeDView()
rw = view.renderWindow()

ren = rw.GetRenderers().GetFirstRenderer()

fp = ren.GetActiveCamera().GetFocalPoint()

cube = vtk.vtkCubeSource()
cube.SetCenter(fp[0], fp[1], fp[2])
cube.SetXLength(100)
cube.SetYLength(100)
cube.SetZLength(100)

mapper = vtk.vtkPolyDataMapper()
mapper.SetInputConnection(cube.GetOutputPort())

testActor = vtk.vtkActor()
testActor.SetMapper(mapper)
testActor.GetProperty().SetRepresentationToWireframe()
testActor.GetProperty().SetLineWidth(3)
testActor.GetProperty().SetOpacity(1.0)

ren.AddActor(testActor)

print("CUBE RENDER START")
rw.Render()
print("CUBE RENDER COMPLETE")

The result was:

CUBE RENDER START
CUBE RENDER COMPLETE

Slicer remained responsive.

Therefore, Slicer’s main 3D renderer can also render additional VTK actors while Volume Rendering is active.

Most important finding: Markups ROI interaction handles

We then created a Markups ROI programmatically while rendering was temporarily paused.

Before allowing its first render, the ROI was configured as follows:

d.SetFillVisibility(False)
d.SetOutlineVisibility(True)
d.SetOccludedVisibility(False)
d.SetHandlesInteractive(False)
d.SetPropertiesLabelVisibility(False)

Rendering was resumed.

Result: the ROI appeared and Slicer remained completely responsive.

In other words:

Volume Rendering + Markups ROI with interaction handles disabled = WORKS.

We then enabled the interaction handles:

d = roi.GetDisplayNode()

d.SetFillVisibility(False)
d.SetOccludedVisibility(False)

d.SetHandlesInteractive(True)
d.SetTranslationHandleVisibility(True)
d.SetRotationHandleVisibility(True)
d.SetScaleHandleVisibility(True)

print("HANDLE TEST START")
slicer.app.processEvents()
slicer.app.forceRenderAllViews()
print("HANDLE TEST COMPLETE")

Slicer froze immediately.

This is currently the most specific and reproducible trigger we have identified.

Therefore:

Markups ROI without interaction handles → works
Enabling Markups ROI interaction handles → immediate freeze

This occurred with Volume Rendering active.

CPU Volume Rendering

I also switched from GPU ray casting to CPU Volume Rendering.

The ROI interaction still caused the application to freeze.

Therefore, this does not appear to be specific to vtkGPUVolumeRayCastMapper.

Earlier transparency observation

During earlier testing of one of my custom modules, a simple spherical model could be displayed at 100% opacity, while lowering its opacity initially caused a freeze.

Disabling depth peeling allowed that translucent sphere to work.

However, the later direct VTK tests described above showed that simple VTK transparency itself works correctly, and the ROI interaction-handle freeze remains even with all renderer depth-peeling flags explicitly disabled.

Therefore, I believe the ROI interaction-handle result is currently the more specific finding.

What appears to have been ruled out

Based on these tests, the problem does not appear to be simply:

  • a corrupted custom extension;

  • my scripted modules;

  • a corrupted Slicer installation;

  • Slicer user preferences;

  • a leftover Slicer registry entry;

  • one particular Slicer version;

  • one particular AMD driver version;

  • general inability of the Radeon 8060S to render 3D;

  • general OpenGL failure;

  • general VTK translucent polydata failure;

  • general VTK GPU Volume Rendering failure;

  • general simultaneous rendering of a volume and translucent actor;

  • Slicer’s basic main 3D renderer;

  • or depth peeling alone.

The current evidence seems to point more specifically toward the Markups 3D interaction-widget / interaction-handle rendering path, potentially in combination with this particular hardware/OpenGL environment.

What remains unexplained

The part I find particularly confusing is the chronology.

This exact laptop initially ran Slicer normally for approximately one month, including my normal 3D workflow.

The problem appeared around the time I attempted to migrate from Slicer 5.10 to Slicer 5.12.3.

However, after the problem appeared, returning to 5.10 did not solve it.

Even a complete Windows reset and clean Slicer reinstall did not restore the previous working behavior.

Therefore, I cannot determine whether:

  1. the timing of the 5.12.3 installation was coincidental;

  2. an OS/graphics/runtime component changed at approximately the same time;

  3. Slicer 5.12 exposed a latent interaction-widget/OpenGL issue;

  4. there is a persistent system-level graphics/runtime condition that Windows Reset did not change;

  5. or there is another explanation specific to Markups interaction rendering.

Request

Could you please advise whether this resembles any known issue involving:

  • vtkSlicerMarkupsInteractionWidgetRepresentation

  • Markups ROI 3D interaction handles

  • interaction renderers/layers

  • Radeon 8060S / recent AMD OpenGL implementations

  • VTK OpenGL state management

  • or Markups interaction widgets combined with Volume Rendering?

If useful, I would be happy to provide:

  • full Slicer application logs;

  • Windows Event Viewer reports;

  • crash/hang dumps;

  • exact Python reproducer scripts;

  • screenshots/video of the freeze;

  • Slicer system information;

  • complete OpenGL capability output;

  • or test a patched build / Preview build / specific VTK change that you recommend.

At this stage I would particularly appreciate guidance on how to obtain a useful stack trace or hang dump while the Markups interaction handles are causing the freeze, since that may help identify exactly where the rendering thread is blocked.

I have spent considerable time trying to isolate this issue, and the current minimal distinction — ROI works with interaction handles disabled but freezes immediately when they are enabled — is the most reproducible finding so far.

Thank you very much for your time and assistance.

Best regards,

Vedat Öztürk, MD
Orthopaedic Surgeon
Istanbul, Türkiye

2

You can try removing the settings file (or the entire Slicer settings folder) - Application settings — 3D Slicer documentation

You can also try to downgrade your graphics driver to a few versions that were released half year to 1-2 years ago.

It may also be possible that some software that you installed interferes. Check the list of DLLs that the SlicerApp-real.exe process loaded and see if anything looks out of place (such as a non-system DLL that is loaded outside of the Slicer folder).

It seems that you could use an LLM quite effectively to diagnose the problem, so you may also be able to build Slicer in debug mode, which would allow you to get detailed call stack and even add debug logs and instrumentation. If you have a debug-mode build and a way to reproduce the issue in debug mode but you are not sure how to resolve the problem then you could ask a quick meeting with a Slicer developer to check what’s wrong.