max2027 crashes when using maxscript to display a WPF window

[lgedZV4XV]

In 3dsmax 2027, any WPF window created with maxscript will crash when show it, for example:

(dotnetObject "System.Windows.Window").Show()

[A娘]

all be right except show by dynamic create , when create by xaml , no error
when dynamic create by c# , show by maxscript will crash immediately same as create by maxscript, show by c# won't , but click anything will crash 

[denisT.MaxDoctor]

Unfortunately, this behavior points to a fundamental problem in the Max 2027 ↔ WPF integration layer.

It is clearly a bug. If we cannot wait for an official fix and need our existing tools to work right now, then the realistic options are either to simplify the implementation to pure XAML or to move away from WPF entirely.

[maxencodingY5SNH]

After testing, I found a reliable workaround for the WPF crashes I encountered in 3ds Max 2027.

Instead of allowing MaxScript to directly access or manipulate WPF objects, I encapsulated the UI interaction inside a C# API layer. MaxScript only calls methods exposed by this API, while all WPF updates and control manipulation are performed entirely within C#.

Architecture:

MaxScript
    ↓
PluginApi (C#)
    ↓
WPF UI

In my tests:

MaxScript → WPF objects directly
    = crash

MaxScript → C# API → WPF
    = stable

This suggests that the issue may be related to direct MaxScript-to-WPF interaction rather than WPF itself. Keeping MaxScript isolated from WPF objects appears to be a practical workaround.

[denisT.MaxDoctor]

A simple, working MXS snippet would be good.

[trykle]

This looks very much like a cross-thread access issue. The thread executing MaxScript is not the same as the WPF thread. Although this was fixed in version 2027.2, it still causes a lot of headaches for many plugins that heavily rely on WPF. By the way, if you strictly adhere to the MVVM pattern when developing WPF, this error won't bother you at all.

[denisT.MaxDoctor]

Could you elaborate on which specific cross-thread operation is happening here and how MVVM would prevent it?

MVVM is an architectural pattern, not a threading model.

Cross-thread access problems are usually solved by marshaling calls through the Dispatcher, regardless of whether the code uses MVVM, MVP, code-behind, or any other UI architecture.

Could you explain what exactly MVVM changes in this particular case?

[trykle]

The suspicion of cross-threading is a guess based on the crash that occurs when accessing WPF objects within MaxScript. The MVVM pattern avoids exposing WPF controls to MaxScript, which indirectly resolves this issue.

[denisT.MaxDoctor]

Avoiding direct access to WPF controls from MAXScript may be a valid architecture for a compiled WPF plugin, but it does not answer the issue being discussed here.

The problem is specifically that WPF does not seem to work reliably when created or accessed from MAXScript in Max 2027.

[denisT.MaxDoctor]

In a situation where WPF does not work correctly with MAXScript, the solution is indeed to stop using either MAXScript or WPF. At that point everything works fine.

The question here is not how to avoid the problem. The question is why the MAXScript ↔ WPF integration appears to be broken in Max 2027.

[denisT.MaxDoctor]

If the choice is between avoiding MAXScript or avoiding WPF, I would argue that WPF is the more questionable dependency.

Outside of the Ribbon, I struggle to think of any major 3ds Max feature that truly benefited from WPF. Which makes me wonder whether adopting WPF as a significant part of the Max ecosystem was ever worth the complexity it introduced.

[Mr.Drm]

For me, WPF is first and foremost about developing any UI controls I can think of. It’s turned out to be really convenient.
But the fact that I’ll have to “bury” all of this because of Max2027 really gets me down.😭

[denisT.MaxDoctor]

---

@Mr.Drm wrote:

For me, WPF is first and foremost about developing any UI controls I can think of. It’s turned out to be really convenient.
But the fact that I’ll have to “bury” all of this because of Max2027 really gets me down.😭

---

Maybe you shouldn't be sad about burying it. Let it go... only then will you find true freedom. 

😁

[Mr.Drm]

Wouldn't it have been more logical to fix the bug in one place rather than have thousands of developers abandon years of work and disrupt their tech stack?

[denisT.MaxDoctor]

This guy claims he knows how to get around the problem... but he doesn't give any examples.

Without examples, it's just empty talk.

[spacefrog_]

---

@Mr.Drm wrote:

Wouldn't it have been more logical to fix the bug in one place rather than have thousands of developers abandon years of work and disrupt their tech stack?

---

Patience, patience 😉 ...  i'm sure it will get a fix

[denisT.MaxDoctor]

---

@spacefrog_ wrote:

---

@Mr.Drm wrote:

Wouldn't it have been more logical to fix the bug in one place rather than have thousands of developers abandon years of work and disrupt their tech stack?

---

Patience, patience 😉 ...  i'm sure it will get a fix

---

... You just have to believe. 

😂

[spacefrog_]

Yes indeed 😂

Being on beta helps too...

[spacefrog_]

3ds Max 2027.2 has been finally released.

This mxs/WPF window crash bug is fixed as far i have tested it ...