Bene

After porting my patch sources from 6.08 to 6.17 (Max WIN32 on 64bit WIN7 system) I was building a standalone as always. The difference was that I had constant crashes when quitting the 6.17 built standalone (always in the ntdll.dll module, not very helpful...).

It´s a standalone that has 4 render contexts on 4 window outputs with 5 monitors attached, which always worked fine under 6.08.

After searching for days (and nights) I finally found the reason:

When setting "Status Window visible..." in the standalone object to 0, the standalone crashes on quit. Setting it to 1, quitting the standalone works without crashing on quit.

Unfortunately I don´t want to have that window visible.

After porting my patch sources from 6.08 to 6.17 (Max WIN32 on 64bit WIN7 system) I was building a standalone as always. The difference was that I had constant crashes when quitting the 6.17 built standalone (always in the ntdll.dll module, not very helpful...).
It´s a standalone that has 4 render contexts on 4 window outputs with 5 monitors attached, which always worked fine under 6.08.
After searching for days (and nights) I finally found the reason:
When setting "Status Window visible..." in the standalone object to 0, the standalone crashes on quit. Setting it to 1, quitting the standalone works without crashing on quit.
Unfortunately I don´t want to have that window visible.
Any help is highly appreciated...

bug-standalone-6-08-vs-6-17-status-window-visible-01

[bump] Am I really the only one? If someone with (german) WIN7 64bit and a 32bit Max running on it could build the attached tiny little patch as a standalone ("Status Window visible…" in the standalone object to 0) and tell me the result it would be of big help.

The demo patch consists just of 4 jit.windows and one standalone object, constantly crashing on quit in ntdll.dll.

We tried now for one month any possible reason (reinstalling Max, reinstalling new PC etc.) for the behavior and are as clueless as before...

Last idea is, it' s a language related WIN7 Max Standalone thing?

We tried now for one month any possible reason (reinstalling Max, reinstalling new PC etc.) for the behavior and are as clueless as before...
Last idea is, it' s a language related WIN7  Max Standalone thing?

I can confirm this. We were running into the same issues ourselves with our compiled Max-app (great super-sleuthing, Bene...saved us a few weeks trying to track this down!). Windows 8.1 64-bit. Max 6.1.8 32-bit.

I don't have a solution, only confirming that we are running into the same problem, and that turning off the hiding of the max window via the standalone object solves it.

I can confirm this. We were running into the same issues ourselves with our compiled Max-app (great super-sleuthing, Bene...saved us a few weeks trying to track this down!). Windows 8.1 64-bit. Max 6.1.8 32-bit. 

Good to hear that we are not the only ones, bad for you to have this trouble too.

Until now the problem is not really solved.

We (seemingly) tracked it down to a problem of system language. But at the end this is only a half satisfying solution.

We created two different standalone versions (Crashgerquit, Crashengquit, link below).

We could verify on 8.1, if you INSTALL Max (always delete/uninstall all Max stuff before) on a US English system and build the standalone (Crashengquit), it runs without crash on quit on 8.1, but crashes on quit on WIN7 64bit Pro.

Crashgerquit was built on a german WIN7 Pro 64bit and crashes on quit no matter if 8.1 or 7.

We tested on about 6 different systems (all maintenance you can apply before, all different kinds of graphics cards etc) which lead to no consistent logic behind that behavior.

It would be interesting if Crashengquit would run on your system without crashonquit.

https://mediencenter.t-online.de/auth/guest/shareToken/53E4CFD05FC593EA5FD4C8466C937D9743D753A3

After months with still no idea why this is happening...

Good to hear that we are not the only ones, bad for you to have this trouble too.
Until now the problem is not really solved.

I've been plagued by these crashes on standalones (Windows 7 64) and didn't understand their cause! The standalones have the status windows invisible as, I guess, it should be in the majority of cases... why would anyone want it opened by default in a finished standalone application?

There's only one difference: in my patch, the crash is visible (a window appears notifying it).

In your patch, on my computer, the standalone crashes silently: the standalone appears to close, but it's still present. So, if I try to open it again, nothing happens. I have to open Resource Monitor, and kill the process. Only then can I open your standalone again.

Did you try to open again the standalone on the computers that didn't appear to crash? Maybe they all crashed...

Cycling74, could you also try to reproduce (and hopefully fix) this problem?

Bene, nice find!
I've been plagued by these crashes on standalones (Windows 7 64) and didn't understand their cause! The standalones have the status windows invisible as, I guess, it should be in the majority of cases... why would anyone want it opened by default in a finished standalone application?

There's only one difference: in my patch, the crash is visible (a window appears notifying it).
In your patch, on my computer, the standalone crashes silently: the standalone appears to close, but it's still present. So, if I try to open it again, nothing happens. I have to open Resource Monitor, and kill the process. Only then can I open your standalone again.

Did you try to open again the standalone on the computers that didn't appear to crash? Maybe they all crashed...
Cycling74, could you also try to reproduce (and hopefully fix) this problem?

[BUG?] standalone 6.08 vs. 6.17 Status Window visible 0/1