At purely random times, DOpus crashes when it's run for the 1st time after a reboot. Don't think it has ever crashed after the 1st one. I didn't see an option in Help to submit the crash log. How do I do that?
Bob Gregory
Help CRASHLOGS
Sorry but I don't see that option
If you need to update customised toolbars from an older version, you can find all the commands under Customize / Default Toolbars:
Or create a new button manually which runs the command from Lxp's post.
I created a new button under Help (Help CRASHLOGS) but I get this when I execute it:
There is a crash log in my temp folder: dopus.20231025.070912.dmp , size: 441KB
Was it under /temp/DOpus.Minidumps? As long as it's not empty, it should appear in the list.
If it's not listed, please zip and email it to: crashdumps@gpsoft.com.au
It was in the Temp folder but not in /temp/dopus.minidumps. I moved it there and I can now submit it.
Thanks.
Many thanks.
If you paste /dopusdata/ConfigFiles/foldercolors.oxc into the path field, it should highlight the config file containing your label assignments.
Would it be possible to zip and email that file to us? It's in a text format, so you can view it to see if it contains anything sensitive. I think one of the filters/patterns inside may be triggering the crash, but haven't been able to find one which does the same thing via experimentation.
Many thanks!
Unfortunately, I still haven't been able to reproduce the crash, or work out how it happened.
If you have any other DMP files, or any more are created, please send them to us, as they might reveal a detail that wasn't in the initial DMP.
will do.
1 Like
Many thanks for the 2 new DMPs.
Those are consistent with the first one, so we at least know we're looking in the right place now, and not dealing with something more random.
I still can't work out how they're happening, though. The default DMP mode doesn't capture a lot of data.
Would it be possible to switch Opus to creating full DMPs and send us one of those the next time one is created? This is done by turning on:
Preferences / Miscellaneous / Advanced: [Troubleshooting] crash_log_memory = True
Note that the DMP will be very large (100-300 MB), which the automatic submitter won't handle. Instead:
- Zip up the DMP. (This should reduce the size a lot.)
- Either email it directly to crashdumps@gpsoft.com.au (GMail is usually fine with large attachment, but not all services are.)
- or use https://wetransfer.com/ and email us a link.
Many thanks! And apologies for it being this involved. We can usually get enough info from the smaller DMPs but in this case it's either missing info or showing misleading info, which can happen if it doesn't capture the right context.
Happy to help. Will be away from the computer for a few hours but will set it up when I return. Had two more crashes since my last post.
1 Like
Just sent you the dump. Had to use http:\wetransfer.com. Gmail kept rejecting it.
2 Likes
Many thanks!
I'm starting to think the problem may be outside of Opus. Even with full detail in the DMP, the crash doesn't make sense vs the code that's running and the data it's running on. That suggests the process state might be corrupted by something. (Although it's not certain.)
I then noticed, in the larger DMP, that AudioDevProps2.dll was doing something that looks strange. That DLL is also in the smaller DMPs, although it wasn't doing anything to draw my attention when those snapshots were made.
A quick search on that DLL reveals it's part of Sonic Studio (and possibly other audio drivers/software that comes with motherboards, including Asus and MSI ones), and is known cause crashes in a lot of games and some other applications, just after they launch: audiodevprops2.dll - Google Search
I then noticed that two versions of that DLL, and another related to it, are both loaded into our process at once. Two DLLs with the same name can cause problems as well.
That combination of a DLL known to cause crashes, which is doing several strange things inside our process, and a crash that doesn't make sense in any normal situation makes me suspect it's that DLL. It may also explain why it only happens just after the system is booted; if it's waiting for another process related to the audio hardware/software to start up. I can't be sure, though; it's only a theory.
Might be worth a try to uninstall that audio software (both copies of it if you can find them), reboot, and see if the problem remains. A lot of the time audio software like that doesn't do anything that useful, although it may depend on which features of the sound hardware you use.
1 Like
Just an FYI, I have had Sonic Studio installed for a long time, and DOPUS 12 never had an issue. I do not use it but I have been having issues with my Microsoft apps just disappearing and when I reinstall them Sonic Studio comes along with them. I will give that a shot although it seems strange that I would now be having problems after all this time.
1 Like
It's possible Opus 13 is causing it to be loaded/used in a way that Opus 12 didn't, in particular for shell columns/properties.
(One of the things I saw in the large DMP which made me start looking into it was a very long callstack where it was being queried for shell properties, ending in it calling Sleep and blocking the thread. But it's more the multitude of threads on the web about it crashing various different things that makes me suspect it.)
I just uninstalled Sonic Studio. It did not uninstall those .DLLs so I tried to delete them but they were in use by 7 of my running applications, Start11, SnagIt, RoboForm, CalendarScope, and a few others. None of those apps use audio as I can tell and I was able to force delete them. I rebooted and those apps seem to be running fine, at least for now. I will try DOpus shortly.
Leo, just an FYI. After I removed those DLLs I started having issues with other applications that I use often. I had to restore my system prior to those deletions so Sonic is installed again. There are 20+ processes using the AudioDevProps2.dll including DOPus. I installed DOPus 13.0.42 so will see what happens. Don't think I want to try this again. My system is back to normal now.
If the DLLs are still there after uninstalling the related software, even after a reboot, and not having them causes problems, then that's something else very strange that they're doing. (Which doesn't surprise me, given the amount of crashes that DLL is responsible for in various software.)
It's possible they are part of two separate applications (probably both related to the motherboard). That would explain why there are two pairs of DLLs with the same in different paths, both being loaded (which itself is a potential problem).