Vectorworks 2025 3.1 AppleT6020/AGXG14X kernal panic crash in Sequoia 15.3.1

[moredillon]

I made the sacrificial mistake of upgrading my OS to current Sequoia 15.3.1 from macOS 14.2.1. Vectorworks is causing a kernel panic and crashing my computer when I move the Vectorworks application window from one display to another. I updated the Vectorworks software from 2025 Update 2.1 to 2025 update 3.1 (Build 796361) which didn’t help.

I have a Apple M2 Max laptop, the built in laptop screen is running at 2056x1329 at 60Hz. There are 2 identical LG HDR 4k external monitors connected to the computer, both monitors are set to resolution of 3360x1890 at 60Hz with the same color profile. The far right LG monitor is connected to the computer via HDMI directly, and the middle LG monitor is connected via displayport to a caldigit thunderbolt station 3 plus dock. The laptop sits to the left of the other two monitors. Vectorworks has been opening on the far right monitor, and the crash happens when I drag it to the middle monitor to the left.

Trying to understand the crash logs I got each time the system rebooted. Here's the identified main issues with the help of chatgpt.

From the crash log, the panic appears to be triggered by AppleT6020PlatformErrorHandler.cpp:3468. This points to an issue at the platform-level error handling for the Apple T6020 SoC
The crash log originally referenced AppleT6020, which is an Apple Silicon driver component, likely tied to Metal, OpenGL, or memory handling.
The message “AMCC0 DCS GROUP 0 CHANNEL 0 M3_AIC_IRQ_EN_FLD error” indicates an interrupt error in the system-on-chip (SoC) platform.

CPU Halting Errors: The repeated messages about failing to halt CPUs (halt not supported for this configuration) indicate an issue in how the system is managing processor states, potentially due to an incompatibility or a deeper kernel bug.

Debugger Synchronization Failure: The message !! debugger synchronization failed, no stackshot !! suggests a lower-level issue preventing the system from obtaining a valid crash dump.

macOS 15 introduced changes to Metal and graphics memory handling, which may be causing Vectorworks 2025 to issue system calls that trigger a kernel panic.

The AppleT6020PlatformErrorHandler.cpp crash suggests the issue is related to low-level hardware interaction (possibly GPU, CPU power management, or memory allocation).
The presence of Apple Silicon GPU driver AGXG14X (GPU driver) means that GPU acceleration could be triggering the problem.
AGXG14X crash suggests that macOS is failing to handle dynamic display switching.
If Vectorworks requests a Metal rendering context refresh when switching monitors, it could trigger this panic.
Apple has been making major changes to multi-monitor support in macOS Sequoia.
macOS 15 Kernel Bugs (New Display Handling in XNU) system kernel tried to halt CPUs and failed - This could indicate a race condition in WindowServer when switching displays.

I cannot use vectorworks currently and am falling behind in work. Anyone have any issues like this?

[Pat Stanford]

Try running the VW Install Manager and choose Repair form the hamburger menu at the top right.

 

Or Uninstall and Reinstall VW 2025.

[Pat Stanford]

Or the other standard troubleshooting methods:

 

Other standard trouble shooting steps are:

 

1.  Check if the same issue occurs in a new blank document.  If the issue does not exist, import half the layers (with the objects) from the problem file. If the problem exists then you know know it is with that half the layers.  Repeat with a smaller number of layers.  If the problem doesn’t exist import the other half the layers and see if the problem exists.  Sheet Layers can be manually created in the new file and then viewports and objects Copied/Pasted into the new file. Bring Design Layers in before moving the Sheet Layers and Viewports.

 

2. Run the Vectorworks Updater (in the Vectorworks folder in Applications folder). Click on the Advanced button on the right center and then choose Repair. Let this run and see if it solves the problem.

 

3. In Vectorworks Preferences click the Reset button at the bottom left.  This will clear everything in your preferences except your serial number, so you will have to set things back to how you like them. Restart VW and see the problem is fixed.

 

4. Make sure you are not running any "helper" apps that might be interfering with VW.  One way to check is to boot into "Safe Mode".  On a Mac, "Turn on or restart your Mac, then immediately press and hold the Shift key until you see the login window. Log in to your Mac. You might be asked to log in again. On either the first or second login window, you should see “Safe Boot” in the menu bar." Check and see if the problem is gone. If not, then quit VW and restart in normal mode. If the problem is solved then check and see what apps are started a boot time that could be causing problems and turn them off. Anti-Virus software is also a potential source of issues.

 

5. In Vectorworks Preferences:User Folder pane click the Reveal in Finder button to see you user folder in the Finder.  Go back to VW and quit.  Rename your user folder. Restart VW.  It will create a new User folder for you.  Check if the problem is solved.  If it is not, quit VW, delete the new user folder, and change the name back on the original folder.  If the problem is solves then you have to decide what information you need to copy from the original user folder to the new one.

 

6. Uninstall and reinstall VW.

[moredillon]

Thanks for the speedy response Pat, I'm trying to change one thing at a time to deduce whats going on, crashing over and over. I appreciate your additional troubleshooting ideas! Will let you know if I find anything.

[moredillon]

I was operating my monitors at 3360x1890 for legibility. Switching scaling resolution on my monitors to 3840x2160 made the crashes stop. Switching back to 3360x1890 from 3840x2160 made it crash again. The additional load of the scaling (non-default 4k resolution) creates a serious bug. I'll keep my monitors resolution as 3840x2160 until this is sorted out.

[Pat Stanford]

@Gunther Is there any additional information from @moredillon that would help with this issue?

[Gunther]

I was hoping dual monitor issues were a thing of the past, after all the issues we encountered with Sonoma from Apple.  I have yet to hear this issue with Vectorworks specifically and checking with Tech Support for any similar reports.  Searching the web in general, many Mac users encountered new dual monitor issues once updating to Sequoia.  In most cases second displays are completely black or not recognized by the OS.  Continuing to dig and ask around...

 

[moredillon]

I have a Apple M2 Max laptop, the built in laptop screen is running at 2056x1329 at 60Hz. There are 2 identical LG HDR 4k external monitors connected to the computer, both monitors are set to resolution of 3360x1890 at 60Hz with the same color profile. The far right LG monitor is connected to the computer via HDMI directly, and the middle LG monitor is connected via displayport to a caldigit thunderbolt station 3 plus dock. The laptop sits to the left of the other two monitors.

 

Debugger synchronization failed (in system crash log) suggests that the system kernel tried to halt CPUs and failed. This could indicate a race condition in WindowServer when switching displays.

As far as I understand it (could be wrong):

Apple adjusted GPU switching behavior in macOS 15, introduced a new “Surface Sync” model for Metal-based window rendering. Some applications expect one GPU pipeline, but macOS now dynamically reassigns GPU resources between multiple displays. This can cause crashes if an app isn’t optimized for the new GPU switching behavior. Also, Apple now syncs window movement with the display’s refresh cycle, which can cause instability if different refresh rates or connection types are used.

 

I was not switching between a “scaled” and “non-scaled” screen, but heard that can trigger a pipeline switch in the GPU or Incorrect Metal surface synchronization, leading to an application crash.

 

When I set a scaled resolution (3360x1890) instead of native 4K (3840x2160), macOS renders everything at a higher resolution internally (maybe 6720x3780), then scales it down to fit 3360x1890.

Apple’s Metal rendering engine optimizes for native resolution first. When running at a scaled resolution, macOS uses a different GPU pipeline for UI rendering. Non-native resolutions (like 3360x1890) now go through a more complex GPU scaling process. MacOS offloads some display tasks to the GPU, which can cause crashes when applications expect direct framebuffer access.

 

If Vectorworks uses the Metal API for rendering: Metal relies on a fixed framebuffer resolution to optimize performance. When moving a window between scaled and non-scaled displays, macOS dynamically changes the framebuffer resolution. The app is expecting one consistent framebuffer size but macOS dynamically resizes it. Extra GPU memory is used to store multiple framebuffer copies. MacOS Metal rendering might not properly reallocate VRAM when dragging windows between screens.

 

Metal does not handle abrupt framebuffer changes well, leading to corrupted rendering states, loss of sync with the GPU pipeline, hard crashes when the system fails to reallocate GPU memory fast enough.

 

Native 3840x2160 avoids this, at 3840x2160 (“Default for Display”) macOS doesn’t need GPU scaling, everything is rendered directly at that resolution. Less GPU memory is used, and no extra scaling buffers are required.

 

[moredillon]

This is why I normally wait to update my OS. I should have listened to my gut that 15.3 still wasn't enough iterations to work out all the kinks. Haven't had any other monitor related issues. And everything has been smooth after setting my monitors to a 'native' resolution. Will update you if I notice anything else.