Holiday notice: Cycling '74 will be closed on Dec 25th, 26th, and Jan 1st. Manual authorization, support cases, and manual order processing will be delayed.
[BUG?] standalone 6.08 vs. 6.17 Status Window visible 0/1
May 12 2014 | 10:38 pm
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...
bene
- Jun 24 2014 | 6:46 am[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?Thanks for any input,bene
- Sep 14 2014 | 2:02 pmI 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.David
- Sep 15 2014 | 8:31 amGood 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.The test versions:After months with still no idea why this is happening...Bene
- Oct 30 2014 | 10:27 amBene, 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?Thanks.
