Hi on my old Windows computer the old builds work fine but the new ones show this briefly then quit (not showing up in the task manager). The new builds work fine on my regular Windows computer. I’m not sure what to search for…
It’s the window that shows when Unity crashes.
Look at your editor.log file for the stacktrace for when the crash occurred.
Editor.log can be found here:
- Windows: C:\users[yourusername]\AppData\Local\Unity\Editor\Editor.log
My old computer doesn’t have a Unity folder there - I haven’t installed the editor…
Right, then the log files for the player.
You can find the location of all the various log files here: Unity - Manual: Log files
Thanks I hadn’t experienced a crash in my game before… BTW it also said:
========= END OF STACKTRACE ===========
A crash has been intercepted by the crash handler. For call stack and other details, see the latest crash report generated in:
* C:/Users/Owner/AppData/Local/Temp/DefaultCompany/Brutal-Demo-Test/Crashes
It crashes on my regular Windows computer as well. I’ve got it on a USB flash drive. The folder on my regular hard drive doesn’t crash. The folders have the exact same file size and number of files but one folder always crashes and the other doesn’t even when they’re both on the USB flash drive.
Well I’ll try and learn what the crash.dmp files mean.
BTW I’m using Backtrace and it is meant to log crashes to the site but it didn’t…
Can you please attach the entire log file and also post the crash dump (.dmp) found in the “Crash files” folder?
It’s probably some low-level file I/O issue, but it might be worthwhile to see exactly what’s going on.
Running directly from a USB drive isn’t recommended; they’re horribly unreliable.
Here you go…
I think I’ll continue to do this - It makes it easier to test on other computers if I run it from a USB drive. Also I think it is good to try problematic techniques to catch issues early. Note the build is 130 Mb.
Maybe a file got corrupted on the drive though error checking didn’t find any errors.
edit:
The second copy on the USB drive is crashing as well - but only when you load up a level. But on the harddrive it isn’t crashing. I’ve attached a zip for each computer. The other builds in the USB drive don’t seem to crash.
9661376–1375490–Crash_2024-02-23_064618595.zip (16.6 KB)
9661376–1375493–Crash_2024-02-23_214700409.zip (60.5 KB)
In the latest player.log where it crashes when loading a level it says:
Thanks for extra info!
From the first dump, it’s crashing while attempting to allocate memory. Here’s the relevant (native) stack trace:
...
UnityPlayer.dll!DynamicHeapAllocator::Allocate(unsigned __int64,int)
UnityPlayer.dll!DualThreadAllocator<class DynamicHeapAllocator>::Allocate(unsigned __int64,int)
UnityPlayer.dll!MemoryManager::Allocate(unsigned __int64,unsigned __int64,struct MemLabelId,enum AllocateOptions,char const *,int)
UnityPlayer.dll!core::StringStorageDefault<char>::allocate_new_buffer(unsigned __int64)
UnityPlayer.dll!core::StringStorageDefault<char>::grow(unsigned __int64)
UnityPlayer.dll!core::StringStorageDefault<char>::resize(unsigned __int64)
UnityPlayer.dll!StreamedBinaryRead::Transfer<class core::basic_string<char,class core::StringStorageDefault<char> > >(class core::basic_string<char,class core::StringStorageDefault<char> > &,char const *,enum TransferMetaFlags)
UnityPlayer.dll!StreamedBinaryRead::Transfer<struct dynamic_array<class core::basic_string<char,class core::StringStorageDefault<char> >,0> >(struct dynamic_array<class core::basic_string<char,class core::StringStorageDefault<char> >,0> &,char const *,enum TransferMetaFlags)
UnityPlayer.dll!BuildSettings::Transfer<class StreamedBinaryRead>(class StreamedBinaryRead &)
UnityPlayer.dll!SerializedFile::ReadObject(__int64,enum ObjectCreationMode,bool,class TypeTree const * *,bool *,class Object &,class CacheReaderBase *)
...
The log file message “Size overflow in allocator.” corresponds to this code:
if (realSize > 32)
{
size_t tlsfalign = (1 << HighestBit(realSize >> 5)) - 1;
if (DoesAdditionOverflow(realSize, tlsfalign))
{
FatalErrorMsg("Size overflow in allocator.");
return NULL;
}
realSize = (realSize + tlsfalign) & ~tlsfalign;
}
It appears garbage data is being passed into the allocator, causing it to abort, which is coming from a String object trying to deserialize data via StreamedBinaryRead::Transfer().
The second dump is different and has this stack:
...
UnityPlayer.dll!CachedReader::OutOfBoundsError(unsigned __int64,unsigned __int64)
UnityPlayer.dll!CachedReader::UpdateReadCache(void *,unsigned __int64)
UnityPlayer.dll!TransferPPtr<class StreamedBinaryRead>(int &,class StreamedBinaryRead &)
UnityPlayer.dll!Renderer::Transfer<class StreamedBinaryRead>(class StreamedBinaryRead &)
UnityPlayer.dll!ParticleSystemRenderer::Transfer<class StreamedBinaryRead>(class StreamedBinaryRead &)
UnityPlayer.dll!SerializedFile::ReadObject(__int64,enum ObjectCreationMode,bool,class TypeTree const * *,bool *,class Object &,class CacheReaderBase *)
UnityPlayer.dll!PersistentManager::ReadAndActivateObjectThreaded(int,struct SerializedObjectIdentifier const &,class SerializedFile *,bool,bool,enum PersistentManager::LockFlags)
UnityPlayer.dll!PersistentManager::LoadObjectsThreaded(int const *,int,class LoadProgress &,bool,enum PersistentManager::LockFlags,bool)
UnityPlayer.dll!LoadSceneOperation::Perform(void)
...
But it seems to indicate a similar problem with the log message “The file ‘G:/Crashing build/Graphics settings tooltips/Brutal-Demo-Test_Data/sharedassets4.assets’ is corrupted! Remove it and launch unity again!” corresponding to this code:
if (position + size > m_Cacher->GetFileLength())
{
FatalErrorString("The file \'" + GetNicePath(*m_Cacher) + "\' is corrupted! Remove it and launch unity again!\n[Position out of bounds!]");
m_OutOfBoundsRead = true;
}
if (position + size > m_MaximumPosition)
{
FatalErrorString("The file \'" + GetNicePath(*m_Cacher) + "\' is corrupted! Remove it and launch unity again!\n[Position out of bounds!]");
m_OutOfBoundsRead = true;
}
if (position < m_MinimumPosition)
{
FatalErrorString("The file \'" + GetNicePath(*m_Cacher) + "\' is corrupted! Remove it and launch unity again!\n[Position out of bounds!]");
m_OutOfBoundsRead = true;
}
Again it appears the “size” variable is holding garbage data.
So, all that to say, it appears a corrupted asset is passing up a garbage “size” value causing Unity to abort. I don’t think there’s anything we can do about this; corrupted data is going to cause the app to malfunction. Still it’s worth looking into in case there is a bug that can be addressed.
To me that suggest your USB drive has bad sectors/blocks and maybe using a repair tool can help fix it.
I hope this is helpful.
Thanks!
I was wondering how you were able to see the stack trace and code just from the zips I provided…? I can’t see that information when I open crash.dmp in Visual Studio 2022.
When I replaced sharedassets4.assets in the second copy it stopped crashing. In the Windows command prompt it has different hashes when I use
certutil -hashfile sharedassets4.assets MD5
When I use CHKDSK in the command prompt for the USB drive it says there aren’t any bad sectors. I also tried “Error checking” in Windows though there definitely seems to be some issue with the USB drive.
BTW do you know if Cloud Diagnostics is set up properly would it send information about those 2 crashes (one early crash one later) to the server? It doesn’t seem to do that with Backtrace.
Shhh…I’m a Unity Employee but removed the tag from my profile to avoid harassment due to…certain decisions by the company’s executive managers. Also I’m slammed with work right now and don’t have time to respond to questions as much as I would like.
That’s interesting…and weird. I guess it really was a corrupted asset; maybe something went wrong when saving it? this sort of thing is very rare but it does happen.
Well regardless, I’m glad you’re able to get it working 
1 Like