How to debug (Windows) crash with no stack trace in the log?

JoeStrout · July 28, 2015, 5:18am

We have a crash that’s occurring in a built app for Windows. The app is in the same folder as its .pdb files, and it’s generating an output.log, but the output.log doesn’t contain any useful information. Here’s the tail end of the log (with most of the DLL version dump trimmed for brevity):

Error: Cannot create FMOD::Sound instance for resource resources.resource, (Unsupported file or audio format. )
(Filename:  Line: 857)

Error: Cannot create FMOD::Sound instance for resource resources.resource, (Unsupported file or audio format. )
(Filename:  Line: 857)

Crash!!!
SymInit: Symbol-SearchPath: '.;C:\Users\Sean\Dropbox\Chesster (2);C:\Users\Sean\Dropbox\Chesster (2);C:\Windows;C:\Windows\system32;SRV*C:\websymbols*http://msdl.microsoft.com/download/symbols;', symOptions: 530, UserName: 'Sean'
OS-Version: 6.1.7601 (Service Pack 1) 0x300-0x1
C:\Users\Sean\Dropbox\Chesster (2)\Chesster.exe:Chesster.exe (01300000), size: 16887808 (result: 0), SymType: 'PDB', PDB: '.\player_win_x86.pdb', fileVersion: 5.1.0.28848
C:\Windows\SysWOW64\ntdll.dll:ntdll.dll (77850000), size: 1572864 (result: 0), SymType: '-exported-', PDB: 'C:\Windows\SysWOW64\ntdll.dll', fileVersion: 6.1.7601.18869
C:\Windows\syswow64\kernel32.dll:kernel32.dll (75CE0000), size: 1114112 (result: 0), SymType: '-exported-', PDB: 'C:\Windows\syswow64\kernel32.dll', fileVersion: 6.1.7601.18869
C:\Windows\syswow64\KERNELBASE.dll:KERNELBASE.dll (76190000), size: 290816 (result: 0), SymType: '-exported-', PDB: 'C:\Windows\syswow64\KERNELBASE.dll', fileVersion: 6.1.7601.18869
...
C:\Windows\system32\dbghelp.dll:dbghelp.dll (70730000), size: 962560 (result: 0), SymType: '-exported-', PDB: 'C:\Windows\system32\dbghelp.dll', fileVersion: 6.1.7601.17514

========== OUTPUTING STACK TRACE ==================

…and that’s the end. No stack trace was actually output.

I believe the FMOD errors at the top are unrelated, because I got dozens of those over the course of play, and they don’t appear to affect anything. So basically, as far as the log goes, we’re just playing along, and then “Crash!!!”, and no stack trace.

Any suggestions on how to determine what’s causing this crash?

karl_jones · July 28, 2015, 12:10pm

Can you see anything in the event viewer?
http://www.cyberlink.com/support/faq-content.do?id=10449

JoeStrout · July 31, 2015, 2:00pm

We managed to catch one with that (thanks for the link). Not very enlightening to me; can you spot anything useful in it?
error reports from the event viewer

Three Information level events in the Event Viewer during the time. Source was “Windows Error Reporting”

#1

Fault bucket , type 0
Event Name: WindowsWcpOtherFailure3
Response: Not available
Cab Id: 0

Problem signature:
P1: 6.1.7601
P2: base\wcp\sil\merged\ntu\ntsystem.cpp
P3: Windows::Rtl::SystemImplementation:irectFileSystemProvider::SysCreateFile
P4: 2057
P5: c00000ba
P6: 0x5fd77dfb
P7:
P8:
P9:
P10:

Attached files:
C:\Windows\Logs\CBS\CbsPersist_20150514114806.cab
C:\Windows\Logs\CBS\CbsPersist_20150518130548.cab
C:\Windows\Logs\CBS\CbsPersist_20150601034453.cab
C:\Windows\Logs\CBS\CbsPersist_20150603004137.cab
C:\Windows\Logs\CBS\CbsPersist_20150604133351.cab
C:\Windows\Logs\CBS\CbsPersist_20150724070014.log
C:\Windows\Logs\CBS\CBS.log
C:\Windows\servicing\Sessions\Sessions.xml
C:\Windows\winsxs\poqexec.log
C:\Windows\System32\LogFiles\Scm\SCM.EVM
C:\Windows\Logs\CBS\FilterList.log
C:\Windows\Temp\WERD59E.tmp.hdmp
C:\Windows\Temp\WERD6E6.tmp.mdmp

These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\Critical_6.1.7601_6a124451c0dd694df41dd4cbf3a58d2da1668db_cab_135ad7b0

Analysis symbol:
Rechecking for solution: 0
Report Id: 45d0f49e-372a-11e5-8ef5-002683195283
Report Status: 4

#2

Fault bucket , type 0
Event Name: WindowsWcpOtherFailure3
Response: Not available
Cab Id: 0

Problem signature:
P1: 6.1.7601
P2: base\wcp\sil\merged\ntu\ntsystem.cpp
P3: Windows::Rtl::SystemImplementation:irectFileSystemProvider::SysCreateFile
P4: 2057
P5: c00000ba
P6: 0x5fd77dfb
P7:
P8:
P9:
P10:

Attached files:
C:\Windows\Logs\CBS\CbsPersist_20150514114806.cab
C:\Windows\Logs\CBS\CbsPersist_20150518130548.cab
C:\Windows\Logs\CBS\CbsPersist_20150601034453.cab
C:\Windows\Logs\CBS\CbsPersist_20150603004137.cab
C:\Windows\Logs\CBS\CbsPersist_20150604133351.cab
C:\Windows\Logs\CBS\CbsPersist_20150724070014.log
C:\Windows\Logs\CBS\CBS.log
C:\Windows\servicing\Sessions\Sessions.xml
C:\Windows\winsxs\poqexec.log
C:\Windows\System32\LogFiles\Scm\SCM.EVM
C:\Windows\Logs\CBS\FilterList.log

These files may be available here:

Analysis symbol:
Rechecking for solution: 0
Report Id: 45d0f49e-372a-11e5-8ef5-002683195283

#3

Fault bucket 1595788587, type 21
Event Name: WindowsWcpOtherFailure3
Response: Not available
Cab Id: 0

Problem signature:
P1: 6.1.7601
P2: base\wcp\sil\merged\ntu\ntsystem.cpp
P3: Windows::Rtl::SystemImplementation:irectFileSystemProvider::SysCreateFile
P4: 2057
P5: c00000ba
P6: 0x5fd77dfb
P7:
P8:
P9:
P10:

Attached files:
C:\Windows\Logs\CBS\CbsPersist_20150514114806.cab
C:\Windows\Logs\CBS\CbsPersist_20150518130548.cab
C:\Windows\Logs\CBS\CbsPersist_20150601034453.cab
C:\Windows\Logs\CBS\CbsPersist_20150603004137.cab
C:\Windows\Logs\CBS\CbsPersist_20150604133351.cab
C:\Windows\Logs\CBS\CbsPersist_20150724070014.log
C:\Windows\Logs\CBS\CBS.log
C:\Windows\servicing\Sessions\Sessions.xml
C:\Windows\winsxs\poqexec.log
C:\Windows\System32\LogFiles\Scm\SCM.EVM
C:\Windows\Logs\CBS\FilterList.log
C:\Windows\Temp\WERD59E.tmp.hdmp
C:\Windows\Temp\WERD6E6.tmp.mdmp

These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportArchive\Critical_6.1.7601_6a124451c0dd694df41dd4cbf3a58d2da1668db_04dc1ff6

Analysis symbol:
Rechecking for solution: 0
Report Id: 45d0f49e-372a-11e5-8ef5-002683195283

The tester described it as: “upon returning to [the level-select scene, or ‘map’] the background displayed stretched across the screen for a spit second, then the map popped back in, game freezes. Music was turned all the way down but was playing after the freeze.”

It’s a pretty rare crash; I’ve never been able to reproduce it here. But obviously important to fix. Any ideas will be greatly appreciated.

karl_jones · July 31, 2015, 2:57pm

Looks like something to do with a file I/O?
Perhaps try running something like xperf to see if that can give you more:
http://blogs.unity3d.com/2015/01/10/curious-case-of-slow-texture-importing-and-xperf/

JoeStrout · July 31, 2015, 4:11pm

Hmm, file I/O is possible here, we’re using PlayerPrefs to keep track of which levels you have unlocked, etc. At the points where the crash has been observed, it would fit with places where we’re writing to PlayerPrefs.

However, I’m not sure xperf is going to help us here; the crash is only seen every couple of days, despite hours of testing each day. Is there really no way for Windows to get a traceback at the point where the crash occurs? (Unfortunately the crash hasn’t occurred on a Mac, but this could be just because almost all the testing has to be done under Windows.)

Are there any known crash issues with PlayerPrefs? I tried searching the bug base, and didn’t find any, but the search options available to us are pretty limited — perhaps you have ways to do a more powerful search?

EDIT: Of course PlayerPrefs isn’t the only place file I/O happens; I imagine Resources.Load and lots of other things probably read from disk. And the standalone player is also writing to output_log quite a lot, etc. So really I suppose it could be anything.

JoeStrout · July 31, 2015, 4:17pm

One more thought: the tester is running the app out of a live Dropbox folder. I’m thinking that Dropbox and the app might occasionally get into a tussle over the output_log file or some such. I’ve asked him to try turning off Dropbox syncing while working with the game, so we’ll see. But I thought I’d mention it in case that triggers an “Aha!” for anybody.

karl_jones · July 31, 2015, 4:55pm

I don’t know about dropbox specifically but I have had problems with other cloud systems in the past, I would not recommended working in a dropbox folder. If you need source control try git, much cleaner and safer than dropbox.

JoeStrout · July 31, 2015, 5:36pm

Heh — we use subversion, which we find much cleaner and easier than git. Dropbox is not for version control; it’s for sharing files (including the build) among the team. I do a “Build & Run” right into Dropbox, and my designers/testers automatically have a new build to use. They update the text files that define puzzles, challenges, board layouts, etc., and these automatically appear on my machine. It’s all very fool-proof and easy.

BUT, it could be that running the builds from a dropbox folder is a potential source of problems. We’ll see if the problem occurs with syncing turned off (when you turn Dropbox syncing off, they are just ordinary folders). Of course since the problem is so danged intermittent, it might to take a while to be sure.

Topic		Replies	Views
Unityplayer is crashing on Windows 10 store apps Unity Engine Windows , Platforms	9	2494	February 21, 2016
How to debug a Unity app that crashes with no error? Unity Engine Advanced , C-Sharp , Question , 6-1	8	965	June 11, 2025
Debugging UWP crash on certain PCs Unity Engine Windows , Platforms	12	5436	July 2, 2017
Utilizing crash.dmp files Unity Engine	40	30279	September 30, 2020
How to diagnose a crash? Unity Engine Windows , Platforms	11	3625	February 12, 2016

How to debug (Windows) crash with no stack trace in the log?

Related topics