What about rev4300? Does it crash as many times as 4301 does?
Not so much, 4300 was more stable. It could crash too, but not while editing. 4300 crashed mostly when you run the table or on exit. But I have not reported those crash since I usually have open a VP9 table to copy something of simply to check something, and I know VPX and VP9 don't go along
hmm strange...4301 doesn't have any code changes it's only the updated FreeImage.dll that was changed. Your crash dump looks like it crashed while exiting the player. Unfortunately it doesn't point to something interesting.
got a crash dump finally
Crash report VPX rev4301============Process: VPinball beta 10.7.4301.exeReason: 0xC0000005 - EXCEPTION_ACCESS_VIOLATION at 0023:00539D82Attempt to read from 0x00000000Thread ID: 0xBE0 [3040]Call stack==========00539D82 VPinball beta 10.7.4301.exe (0x0030045E 0x0019F36C 0x00000001 0x0019f36c)004902FF VPinball beta 10.7.4301.exe (0x0019EBB0 0x0030045E 0x0030045E 0x0019d4a4)00427AC2 VPinball beta 10.7.4301.exe (0x00755648 0x00A708C4 0x00000000 0x0073e170)Environment===========Date/time: 26/9/2020, 22:28:30:606Number of CPUs: 8Processor type: 586System: Windows 10 (10.0 19041)Memory status=============Total Reserved: 81308K (79M) bytesTotal Commited: 501776K (490M) bytesTotal Free: 3611156K (3526M) bytesLargest Free: 2095424K (2046M) bytesRegisters=========EAX=00000000 EBX=031A5FC0 ECX=00000000 EDX=0000000FESI=06539190 EDI=00000004 EBP=00000000 ESP=0019EC14 EIP=773B4A75FLG=00010202 CS=0023 DS=002B SS=002B ES=002B FS=0053 GS=002BMini dump saved successfully.the mini dump is 3.8gb
If you need that, it will take me a while to upload it.
What about rev4300? Does it crash as many times as 4301 does?
It sort of does seem so.
I just had it exit on me now.
It for some reason, does not consistently leave a crash txt and dump
It also seems (and it could be an illusion) to not crash so much, with auto save disabled.
Kind if ironic, i turned auto save on and set it for every 3 min, in case the editor crashed (and of course it did not exactly consistently auto save LOL)
And now seems that very thing might be making it crash.
I thought maybe it was doing that because i had my parts table open, and maybe it gave it trouble knowing which one to actually auto save
but seems to be doing it with only 1 table open, so i'm not sure?
The call stack of the crash report points to a null pointer in the sound manager while closing the sound manager dialog. I don't understand why there seems to be a null pointer at all but I changed the code to better handle resources maybe this is fixed in the next update.




Top









are all trademarks of VPFORUMS.