My DOpus crashes intermittently up to several times per day.
It has done this ever since I bought it some 18 months ago, and across several machine rebuild/transfers.
I get the imression that it usually happens while DOpus is in background and I am using a different application, most frequently Firefox.
Dopus pops up from 1 to 30 Error Dialogs
"Directory Opus has encountered a program error and needs to close.
"The Error 0xC00000005) occurred in thread 0x798 at address 0x7d7d283E
Directory Opus Needs to close etc etc
Save lister layout and restart"
When I acknowledge the First error dialog, all the rest, and DOpus closes, and restarts.
I have attached screen scrape of one these occurrences
It's most likely caused by a 3rd party DLL that has been loaded into the Opus process.
You may be able to use the crash address (0x7D7D283E in your screenshot, but it may be different each time the crash occurs) to pinpoint a likely suspect.
Next time the crash occurs:
[ul][li]Leave Opus running.[/li]
[li]Open Process Explorer.[/li]
[li]In Process Explorer, select dopus.exe and push Ctrl-D to show the list of DLLs it has loaded.[/li]
[li]Sort the list of DLLs by the Base column. (Note: Not Image Base, just Base.)[/li]
[li]From the address in the crash message, find the DLL with the highest base which is still below the crash address.[/li][/ul]
Let us know what you find. It's also possible that the crash is happening when a DLL is unloaded but has left windows around which point to its code. (We saw a problem with that recently with some Delphi DLLs.) In those cases the DLL won't be listed in Process Explorer because it's already been unloaded, but hopefully that isn't the case. It's much more likely that whatever is crashing is still in memory.
As an example, using the screenshot below, if the crash address was beteen 0xAB4000 and 0xC230000 then the problem was probably caused by gifanim.dll, which is my Animated GIF plugin. (I doubt that's the cause; just an example.)
The addresses are hexadecimal numbers. Ignore the "0x" prefix (which is just there to tell you they are hexadecimal) and treat them as normal numbers or text strings when comparing them.
On its own, Opus is one of the most stable windows programs available.
"Error 0xC00000005) occurred in thread 0x798 at address 0x7d7d283E" is outside of the Opus address space so you need to look at what else is running on this machine. See if the Process Explorer helps.
If not, you can file an official report through the GPSoftware web site Support page mechanism.
I think your best bet is to look in /temp/DOpus.Minidumps for any recent .dmp files and send them to GPSoftare support so they can investigate the crash in more detail.
Unfortunately since the crash is in a Windows DLL the component that's causing it isn't obvious. It's unlikely to be NTDLL.DLL itself, but something that is calling into it may be th cause. Those minidump files should help GPSoftware get a better picture.
I had two listers open and got another crash with 19 threads crashing,
I noticed from Process explorer that there were a totla of 81 threads running at the time, that sounds like an awful lot. Is that reasonable?
The DLLs immiediately adjaacent to the crash address were Shell32.dll and NTdll.dll, similar to previously,
This time I included the thread list, maybe something interesting in there.
As you say, maybe it's time to let GPSoftware have a look at this one.
81 threads does seem very high, unless you had a lot of windows or lengthy commands running at the time.
I wonder if something is going wrong as each thread tries to shut down, maybe as it detaches from a DLL that's been loaded into the Opus process, and the threads are piling up until some kind of limit is reached?
When it happens again, try selecting some of the threads, particularly the "endthreadex" ones but also some of the others, and click the Stack button to see what sort of stuff they're running. Maybe it'll point to a 3rd party DLL that seems common to all those apparently-hung threads. I think that sort of info is contained in the MiniDumps as well so GPSoftware may be able to access it if you send the dumps their way.
If it was something you could reproduce quickly then I'd say it'd be worth trying out the general slowdown/instability tests, especially disabling anti-virus (since that will hook into every thread), but most of those changes/tests aren't ones you'd wan to leave running for an extended period of time. (e.g. Turning off a/v is fine to test something but turning it off all day is another thing!)
I think I've got this figured, and it goes back to another problem I have had with DOpus since I first started using it.
DOpus doesn't handle .wmv files well. When I use dopus to deal with any wmv file, for every wmv file displayed, thumbnailed, viewed, etc. dopus starts two threads with two handles each pointing to the file.
When I have finished and closed the lister, the file handles are NOT relinquished.
If at some point I deal with any of those wmv files with another application, eventually DOpus crashes with an error box for each of the wmv threads.
I have done extensive testing on previous occasions and conclusively shown that dopus shows this behaviour with wmv files only, not mpeg, avi, mov wma etc
And other similar media management programs release wmv handles gracefully. (If anyone is keen I have a package which demonstrates this)
Does any one else have this problem, I can't believe I am the only person that uses DOpus to manipulate wmv files?
Talking of the number of threads, I have been working for a while sorting media, and since DOpus is not relinquishing the wmv files I now have 547 threads going, and hundreds of file locks open
Many thanks for your investigation. I've been looking into the problem for the last few hours and I think I found the cause. A code fix is attached to this message. Please give it a try and let us know if it solves the problem.
The zip should be installed over Opus 9.1.1.8 only. (It hasn't been tested with earlier versions and may not work with them. Future versions of Opus should contain the fix already.)
Fix download:
[ul][li] Opus9118wmvfix.zip (PGP signature) 386KB[/li][/ul] How to install:
[ul][li]Type /home/viewers into the Location field in Opus to go to your viewers directory.
[/li]
[li]Rename movie.dll to movie.old
[/li]
[li]Rename wma.dll to wma.old
(Note: It is important that the old files no longer have a .dll extension. Other than that, call them whatever you want.)
[/li]
[li]Unpack the attached zip file and go into the 32bit or 64bit folder, depending on your version of Windows/Opus.
[/li]
[li]Copy the replacement movie.dll and wma.dll into your Opus viewers directory.
[/li]
[li]Exit and restart Opus[/li][/ul]After restarting Opus you should be able to delete the two .old files but it might be worth keeping them just in case you need to revert back to them for some reason.
What's in the fix:
[ul][li] Your issue with WMV thumbnail threads not exiting properly.
[/li]
[li] Another issue I noticed where certain uncommon WMV variants would sometimes take a very long time to thumbnail.[/li][/ul]
Great work, it looks like your tweaked dlls have done the trick.
As an aside I have a core duo cpu, and so I have set the number of thumbnailing threads to 3 as recommended.
My lister has three tabs which open media files, a ThumbSorter (Tree&TwoThumbnail Panes), plus the standard Images, and Film Strip tabs.
I run Process Explorer, and watch the threads and the File Handles.
Starting with Standard Explorer Tab browse to directory with 18 wmvs
No File Handles, 26 threads
Open Thumb sorter (which opens the same directory in BOTH thumb panes
file handles open two at a time, and then close. it is very obvious that threads are processing the thumbnails, but now they close gracefully.
Open Images or Filmstrip
2 file handles open for the file showing in the viewer
Now the big difference . . . .
Switch back to explorer tab, all wmv file handles close as soon as focus moves away from tabs with viewers
And the thing which has been my major bugbear since the day I got DOpus, I can now rename the directory, as long as there is no viewer visible.
I will have to see if we survive for any length of time without crashing, but already I can clearly see a difference in the behaviour, so I am confident this will be much better.
Since you abviously have a considerable understanding of DOpus under the skin, how difficult do you think it would be to add the following feature.
One of the few things for which I still use an external program is re-ordering files.
There are times particularly with pictures, and video clips where I need to change the order based on visual content rather than any property of the file or extended info.
I have an "Order Aware" photo manager which allows me to drag and drop thumbnails around a window, and it renames them on the fly to reflect the new order. It would be cool if DOpus could do this.
The other approach is implemented in another tool I use, where thumbs are renamed automatically in the ORDER they are selected, so I can hold ctrl, click thumbs in any random order, hit F2, type in a prefix, and the program automatically adds a number suffix based on the order in which the files were selected. It would be cool if DOpus could do this too
Either one or both of these would be invaluable to me
There's no way to have arbitrary sorting in Opus right now. Files have to be sorted by some criteria, i.e. one of the available columns/fields.
You can only achieve an arbitrary sort by modifying the data in a column/field to get what you want. (e.g. Prefixing filenames with numbers, changing file dates, using the Description column, etc.)
If you want grouping rather than sorting, using sub-directories and Flat-View-Grouped is often a good solution. Or you could create buttons which let you quickly put prefixes on filenames to put them into group A/B/C/etc.
Pity about the arbitrary sorting, both my alternative apps have context menu launch so it s very easy to pop out to them to do the sort, and now that DOpus is not hogging the files that approach works seamlessly now.
I spent some time over the long weekend working with the modded Dlls, and all seems to now work smoothly. Dopus only locks wmv files if they are actually open/playing in a viewer (Images&FilmStrip tabs) or while the Thumbs are being processed when opening a pane with Thumbs enabled.
Viewer Locks are relinquished as soon as focus moves away from a viewer tab, or if it is closed.
Just some more positive feedback.
It is now a couple of weeks since I applied your fixed dlls. I have had no further crashes, even though I have been using DOpus intensively.
It is now a pleasure to use and performs as I require, smoothly and efficiently.
My confidence in DOpus is growing daily, to the point where I may consider using it in it's explorer replacement mode.
