Standalone Memory Crashing in Windows 10
I have an application that I developed that is only affecting some Windows 10 users but not all of them. The application would open then immediately shut down. I saw in the event viewer that it produced an Application Error 1000, Fault Type 4 error when this happens. I looked up some information and did several steps, including SFC, clean booting, reinstalling .NET Framework, etc. None of that worked. Then randomly out of habit I defragmented my drive and suddenly the application now opens. It still produces an Application Error 1000, but type 5 this time. It does not affect the application performance whatsoever.
My question is this: Why? And what can I do to ensure this does not happen for users of this application? So far I am guessing that it has to do with ASLR. Are the standalone applications compiled with the /DYNAMICBASE flag? If this is the case, then is there a workaround for the specific standalone?
I am posting the actual error details below.
Fault 4 error cycle: Fault bucket 1923725877593378771, type 4
Event Name: APPCRASH Response: Not available Cab Id: 0 Problem signature:
P1: Interstream_Windows.exe
P2: 8.0.8.58005
P3: 5d44b1d2
P4: Interstream_Windows.exe
P5: 8.0.8.58005
P6: 5d44b1d2
P7: c0000005
P8: 000000000090a90f
P9:
P10:
Analysis symbol: Rechecking for solution: 0
Report Id: e67385ca-22aa-4211-9cf4-ed3fc989c5e1
Report Status: 268435456 Hashed bucket: c712bd3c5c6c3c2d6ab2727e4b2e0fd3 Cab Guid: 0 This is accompanied by:
Faulting application name: Interstream_Windows.exe, version: 8.0.8.58005, time stamp: 0x5d44b1d2
Faulting module name: Interstream_Windows.exe, version: 8.0.8.58005, time stamp: 0x5d44b1d2
Exception code: 0xc0000005 Fault offset: 0x000000000090a90f
Faulting process id: 0x58dc
Faulting application start time: 0x01d9213ffe2c75f1
Faulting application path: C:\Users\jbernagozzi\Desktop\Interstream_Windows\Interstream_Windows.exe
Faulting module path: C:\Users\jbernagozzi\Desktop\Interstream_Windows\Interstream_Windows.exe Report Id: e67385ca-22aa-4211-9cf4-ed3fc989c5e1
Faulting package full name: Faulting package-relative application ID: Fault 5 is different, here is this code:
Fault bucket 1733984756823260336, type 5 Event
Name: BEX64 Response: Not available Cab Id: 0 Problem signature:
P1: Interstream_Windows.exe
P2: 8.0.8.58005
P3: 5d44b1d2
P4: ucrtbase.dll
P5: 10.0.18362.1110
P6: b4cacc38
P7: 000000000006dace
P8: c0000409
P9: 0000000000000007
P10:
Analysis symbol: Rechecking for solution:
Report Id: 5c9cea6d-60d0-4b5f-ad90-99be23184f85
Report Status: 268435456 Hashed bucket: 66ccab7de70f21c6181059f304647cb0
Faulting application name: Interstream_Windows.exe, version: 8.0.8.58005, time stamp: 0x5d44b1d2
Faulting module name: ucrtbase.dll, version: 10.0.18362.1110, time stamp: 0xb4cacc3
Exception code: 0xc0000409 Fault offset: 0x000000000006dace
Faulting process id: 0x1678 Faulting application start time: 0x01d9216b9f3abbe8
Faulting application path: C:\Users\jbernagozzi\Desktop\Interstream_Windows\Interstream_Windows.exe
Faulting module path: C:\WINDOWS\System32\ucrtbase.dll
Report Id: 5c9cea6d-60d0-4b5f-ad90-99be23184f85
Faulting package full name: Faulting package-relative application ID:
max installs several dlls into system, also ucrtbase.dll
Maybe your users are mising it, have incompatible version, who knows ...
I allway bundle all dlls that max usually installs into standalone
and don't even install max at all but rather extract it using msiexec,
and place dlls next to exe file.
like this
that keeps me out of trouble when using different versions of max,
and makes sure standalones get their versions of needed dlls
when distributed.
That's super interesting. Just to be clear, you do not install Max as normal using windows installer and extract it using msiexec?
Just curious, the application I created has an external that uses specialized .dll's for processing, but it seems to only work in windows on Max version 8.0.8 (its fine on Mac). Could it be that for whatever reason the .dll's are just out of date?
-Jason
I can not say anything without knowing details.
Sometimes also windows versions behave differently
home - pro or enterprise ...
and yes, I never install Max.
I have many Max versions on PC
to be able to apply updates to standalone apps which
have been compiled over years using different max versions.
I don't want surprises when using older code or have to check
which objects changed their behaviour in the meantime.
I have tried the above suggestion and it is still an issue. However I do have some more insight, one other question, if you don't mind?
So we produce a series of apps all done in Max. The common denominator for this app having issues is not the app itself. When people open it for the first time, it works. But if they open another one of our apps and then this one, then it crashes before opening like described above. I wonder if that has to do with memory registry? Is there a way to differentiate this within multiple max standalones? I think this might be the key to the problem, but nothing I have searched for has yielded results.
Thanks for being so generous with your suggestions
I have no problem using several Max Standalones on windows,
even different generations - from max 4 till 8 and also keep them running at same time.
But I allways set own preferences file and info for each app.
That crashing I guess is caused by stuff that your standalones execute.