New Version (12.13) Crashes upon Start, even after reinstall

Hi Everybody!
Got a problem with my beloved Dopus.
Once I start it, it freezes - no reaction at all.

I tried - so far -

  1. Renaming the old Folder in Roaming, and let it buil anew - no change.
  2. Lots of pointless clicking, shouting abuse, restarting the machine.
  3. Redownloading the most current version, uninstalling the old one, running a cleanup, installing, putting in the certificate. No change - all customizations (which I have in a backupfile somewhere else, even though not THAT current) are gone, going as far as the "Default" Lister, then it freezes. Shortcuts (Taking over from Explorer) are working.
  4. Writing this.
    Can anybody help?

Dopus 12.13, Win10, all updates installed.

Greetings from foggy Munich,
Bela

// edit

  • Win10 64bit
  • Installed Universal Version (Not the specific German one, I like Dopus in English)
  • Set to load on startup and react to doubleclicking the Desktop

Sorry you're seeing that problem!

Are any crash dumps created? Please send them to us if they exist, and we might be able to say how to fix things from them. Crash dumps for bug reports

Sometimes a file in the initial folder may trigger a bug in Opus or in a shell extension something else has installed. Crash, exit or high CPU when viewing certain directories

Hi!
Alright I'm trying:
Updating Icaros from 3.0.3 to 3.1.0, reboot, still crashing
Disabled all Plugins in the preferences (By the way, I can still start those), still crashing
Creating Dump-files ....
[link removed for privacy]

Still not Working .....

Truobleshooting on a wednesday - yaaaaay :stuck_out_tongue:

The automated crash dump from Thursday looks like it was triggered by (double) middle-clicking the last tab to close that side of the lister (or the whole lister if that's enabled).

Does that make sense? Maybe it's not the same issue that you're seeing now?

I've made some changes for the next version which should prevent that crash happening again, at least.

(Edit: You can probably ignore this next paragraph. See next reply.) If it's unrelated to the crash you're seeing all the time now, could you try temporarily uninstalling WindowGrid to see if that is involved in some way? It may not be involved, but it's good to rule out tools that hook into other apps like that as they can cause weird issues, especially with the number of windows and threads that Opus uses, which sometimes trigger situations the hook authors didn't consider.

Adding to the previous reply, the other two dumps are manually created so they don't show a crash, just the state of things when the dumps were made.

What was happening at the time they were both made? Was something frozen?

It's interesting that the three active threads in both dumps were all waiting to access the registry. It's unlikely you'd catch all three of them in that state at once unless something was going wrong with or slowing down access to the registry or related APIs. What, I can't really guess from the dumps alone. Have you noticed any strange problems with any other software?

Looks like WindowGrid is not involved in the two manually created dumps, so you can probably ignore that part of my previous reply.

Hi!
The Crash appears when Dopus is trying to load the Tabs (Any tabs at all), and the Start-Lister shows "Empty" and then freezes - the sidebar with the folders is not loading, but I can access the Interface for preferences..
When It shut down last thursday, i wasnt doing anything special - regular office work ....
With your solution (WindowGrid might be the culprit after all, or something else running in the background): I booted Windows into Safe Mode, and only started Dopus - same thing... Then I took a *.dmp
[removed for privacy]
(See here, 208MB)
Task Manager showed Dopus as "inactive", during crashing?
Is it possible that Dopus is looking for something that just isn't there anymore?

Greetings, B

Please try deleting everything under here:

C:\Users\<USERNAME>\AppData\Local\GPSoftware\Directory Opus\State Data

It that doesn't help, what kind of CPU usage do you see while the problem is happening? Is dopus.exe idle or does it look like it's using all of a thread/core, possibly stuck in a loop?

Hi!
I deleted State Data, and the problem persists.
While it is inactive, Dopus takes 10-13% of my CPU -
A Intel i7 7700 with 32 GB Ram at its disposal.
This seems more then it usually does ....

Hm, do you have older versions of Dopus availabe? I could install the previous one, and we'll see if it only happens wit hthe new one (a classic bug) or wit hthe former ones that worked exceptionally well (And therefor must be a fault of my system?)

B

I've sent a private message with a link to a test version.

Please download that, and inside the zip you should find a new dopus.exe

This will only work with 12.13, so make sure you are (still) on that version.

Close down Opus (kill it using Task Manager if the lister is locked up and File > Exit Directory Opus won't work).

Using File Explorer, copy the new dopus.exe over the old one, but don't run it yet.

Grab DebugView from Microsoft and run it. (DebugView doesn't need to be installed, just unzip and run the exe from anywhere.)

Now run Opus. You should see some output in DebugView.

You'll probably need to resize the columns in DebugView to see it properly. They are very narrow by default.

If the crash/freeze still happens, please let us know what DebugView displays with either a screenshot or a text copy of the log (via the File menu in DebugView). I'm also interested in knowing if it keeps rapidly outputting information non-stop, or if it only shows a few things at a time and is generally calm.

The test version has a couple of changes which could potentially fix things on their own, if we're lucky, but the debug output is the main purpose of it.

I'm also uploading some old installers in case we need to narrow down exactly which version the problem started in, but that will take some time.

Many thanks for your help tracking this down.

Hi!
Downloaded, Killed the task, overwrote, startet debug, startetd opus :smiley:
Didnt work, and the result is here:
BELA1.7z (337.1 KB)

The final lines came only after killing it, when I started this message .... hope it helps!

(FYI, I'm on Central European time, and off to work tomorrow, so answers might be delayed. But we'll find the damn mistake! epicfistshakingatthesky)

1 Like

If you wouldn't mind, could you please try beta 12.12.2 to see if this problem occurred with that version?

If it doesn't happen (i.e. if 12.12.2 is ok) then please try beta 12.12.3.

Hopefully this will let us identify when the problem was introduced.

Hi!
Downloaded Opus 1.12.2 , and the same result.....
DebugView says:
[9876] SkypeBridge.exe Information: 0 :
[9876] 2019-04-11 16:47:29.279+02:00 [9876:001] [INFO] Keeping user active
[10680] PPLE [Informational] LIFECYCLE: OnResuming
[9876] SkypeBridge.exe Information: 0 :
[9876] 2019-04-11 16:47:29.333+02:00 [9876:045] [INFO] IdleStateTracker - SendSystemIdleStatusUpdateAsync sent isIdle = False
[10680] PPLE [Informational] LIFECYCLE: OnSuspending

No onwards to 12.12.3

// Edit
Unstialled 12.12.2, ran a cleaner and rebooted.
Installed 12.12.3. Froze again, but there was a change in the Debug-Voew now it said:
[4300] 2019-04-11 17:00:46.077+02:00 [4300:001] [INFO] Keeping user active
[9156] PPLE [Informational] LIFECYCLE: OnResuming
[4300] 2019-04-11 17:00:46.152+02:00 [4300:027] [INFO] IdleStateTracker - SendSystemIdleStatusUpdateAsync sent isIdle = False
[9156] PPLE [Informational] LIFECYCLE: OnSuspending

Would it help if we matched schedules and teamviewered it? (And I know that isn't a proper verb, but it somehow seemed fitting :smiley:

Here are 12.12 and 12.12.1 as well.

If it still happens with 12.12, maybe it isn't a change in Opus but in something else.

(The last lot of debug info is all from other software. These versions don't output anything extra, that was just the special test version I sent.)

Edit, so all the installers are in one post:

Aaaaah, okay - I wondered why Skype was saying things :smiley:

Alright, 12.12. is working!
Yaaaaay! But I have seen something, let me check. I clicked "no" to registering the handler and the explorer replacment and Default FTP and so on ....

// Edit
Damn, that wasn't it - tried my luck again with the current offical version, and no luck, same mistake.... Onwards to 12.12.1

// Edit 2
Alright - onwards. 12.12.1 worked (Slow and a bit hanging, but it got there in the end), 12.12.2 has the problem again. Does this help?

Thanks for doing those checks and narrowing things down.

I've sent a reply to the private message thread with a second test version.

This need to be installed over the top of 12.13 as before.

When you run it initially, I'm hoping that the problem will be gone, because it defaults to bypassing most of the changes that were in 12.12.2.

Assuming that is true, the zip I've sent has a second exe which you can run from anywhere:

This tool lets you turn on and off individual changes from 12.12.2 in the test version. When a box is ticked, the new code is turned back on.

Apart from 02 and 11, you should be able to try each checkbox by turning it on and opening a new window to see if it works or fails.

  • If a test works, leave it on, and try the next one.
  • If a test fails, turn it off and see if the others all work OK.

That should let you go through each test quickly and see if a particular one triggers the crash.

My hope/assumption is that you will be able to turn on all of the checkboxes except one, and that one will point us to where the problem is.

(It's also possible you'll be able to turn them all on, as I've hardcoded a couple of other changes that were difficult to make optional but also less likely to be the problem.)

Many thanks, again!

Alright, let's get to it.
I went down to 12.12., shutting Dopus down - incl. Helper Application. Replacing Dopus.exe with 12.13._test2.
Crossing the fingers
"The installed Versions of critical Directory Opus Components do not match."
Downloading 12.13., installing that.
Overwriting with Test2.exe.
Click AND IT WORKS!
It even took over most of my configuration files from 12.12!
// edit

Test01 - Dopus is working
Test02 - Dopus is working (Restarted)
Test03 - Dopus is working
Test04 - Dopus is working
Test05 - Dopus is working
Test06 - Dopus is working
Test07 - Dopus is working
Test08 - Dopus is working, Getting a fresh cup of coffee
Test09 - Dopus is working
Test10 - DOPUS IS CRASHING - same as before! Turning of Test10, it is back to working.
Test11 - Dopus is working (Restarted)
Test12 - Dopus is working
Test13 - Dopus is working
Test14 - Dopus is working

Everything except Test10 Turned on: Working
Everything Turned on: Crashing.
It seems to be "Test10" is the culprit. What is it?

Many thanks!

Here is a new test version:

Anyone affected is welcome to try this version.

This is 12.13 with all the changes reinstated, except the Test10 one which has had some changes made, and extra debugging added.

Please try that and see if it works.

  • As before, it needs to be used on top of a 12.13 install. Won't work with newer/older versions. (Copying it over the previous test version is fine.)
  • Fully exit Opus (File / Exit Directory Opus), then copy the new dopus.exe over the existing one using File Explorer, and double-click it.

This test version should output some new information via DebugView.

  • Please let us know what the DebugView output says.
  • This information will be useful to us whether the new test version fixes the problem or not.
  • Instructions on how to use DebugView are in this post earlier in the thread.

If the problem still happens, please also:

  • Set Preferences / Miscellaneous / Advanced [Troubleshooting]: shellchange_debug = True
  • You should see some additional information in DebugView which may indicate where the problem is coming from. Let us know what it says.

It's possible this was a bug on our side, in which case the improved code in this new build should help. It's also possible this could be happening if something on the affected systems is constantly generating "drive changed" events, or similar, faster than we can keep up with them. If that is happening we can try adding something to mitigate it, based on the shellchange_debug output.

Thanks to all for helping us get to the bottom of this.

PS: @belabeier only -- Please run the debug settings exe from the previous build and turn off all the tests. That will clear the registry entries it created. Not essential, but keeps things clean. Those entries won't be looked for by the new version.

6 posts were merged into an existing topic: Dopus v12.13 x64 fails to open a lister after awhile

Hi!
it seems to be working -
Unmarked everything in the "Debug Settings Exe,
quit Dopus,
overwrote with the exe,
ran debug, clicked Dopus, and it worked.
Shoved a few files ariound to test, and the output says:

[7812] Suspending
[7112] [3020] dopus: UpdateString would have previously invalided PIDL for "D:\" 
[7112] [3020] dopus: UpdateString would have previously invalided PIDL for "D:\" 
[7112] [3020] dopus: UpdateString would have previously invalided PIDL for "D:\" 
[7112] [3020] dopus: UpdateString would have previously invalided PIDL for "D:\" 
[7112] NPGetCaps 2
[7112]   WNNC_NET_TYPE
[7112] NPGetCaps 4
[7112]   WNNC_USER
[7112] NPGetCaps 6
[7112]   WNC_CONNECTION
[7112] NPGetCaps 13
[7112]   default
[7112] NPGetCaps 11
[7112]   WNNC_ENUMERATION
[7112] NPGetCaps 9
[7112]   WNNC_ADMIN
[7112] NPGetCaps 8
[7112]   WNNC_DIALOG
[7112] NPOpenEnum: dwScope 0x00000001, dwType 0x00000001, dwUsage 0x00000000, lpNetResource 0000000000000000
[7112] NPOpenEnum: pCtx 0000025FAA96FDC0
[7112] NPEnumResource: hEnum 0000025FAA96FDC0, lpcCount 000000C38C7FEE30, lpBuffer 0000025FAAA23F50, lpBufferSize 000000C38C7FEEA0.
[7112] NPEnumResource: *lpcCount 0xffffffff, *lpBufferSize 0x4000, pCtx->index 0
[7112] NPEnumResource: Entries returned 0, dwStatus 0x00000103
[7112] NPCloseEnum: hEnum 0000025FAA96FDC0
[7112] NPCloseEnum: returns
[7112] [3020] dopus: UpdateString would have previously invalided PIDL for "D:\" 
[7112] [12740] dopus: UpdateString would have previously invalided PIDL for "F:\" 
[7112] [12740] dopus: UpdateString would have previously invalided PIDL for "G:\" 
[7112] [3020] dopus: UpdateString would have previously invalided PIDL for "D:\" 
[7112] [3020] dopus: UpdateString would have previously invalided PIDL for "D:\" 
[7112] [3020] dopus: UpdateString would have previously invalided PIDL for "D:\" 
[7112] [3020] dopus: UpdateString would have previously invalided PIDL for "D:\" 
[7112] [3020] dopus: UpdateString would have previously invalided PIDL for "D:\" 
[7112] [3020] dopus: UpdateString would have previously invalided PIDL for "D:\" 
[8304] "www.google.com" 
[8304] "www.amazon.com" 
[8304] "en.wikipedia.org" 
[8304] "www.youtube.com" 
[8304] "maps.google.com" 
[8304] QFSFileEngine::open: No file name specified
[8304] Searching history for "" 
[10500] SkypeBridge.exe Information: 0 : 
[10500] 2019-04-14 13:44:46.496+02:00 [10500:001] [INFO] Keeping user active 
[9324] PPLE [Informational] LIFECYCLE: OnResuming
[10500] SkypeBridge.exe Information: 0 : 
[10500] 2019-04-14 13:44:46.548+02:00 [10500:063] [INFO] IdleStateTracker - SendSystemIdleStatusUpdateAsync sent isIdle = False 
[9324] PPLE [Informational] LIFECYCLE: OnSuspending
[7112] [3020] dopus: UpdateString would have previously invalided PIDL for "D:\" 
[7112] [3020] dopus: UpdateString would have previously invalided PIDL for "D:\" 
[7112] [3020] dopus: UpdateString would have previously invalided PIDL for "D:\" 
[7112] [3020] dopus: UpdateString would have previously invalided PIDL for "D:\" 
[7112] [3020] dopus: UpdateString would have previously invalided PIDL for "D:\" 
[7112] [3020] dopus: UpdateString would have previously invalided PIDL for "D:\" 
[10500] SkypeBridge.exe Information: 0 : 
[10500] 2019-04-14 13:46:26.499+02:00 [10500:001] [INFO] Keeping user active 
[9324] PPLE [Informational] LIFECYCLE: OnResuming
[10500] SkypeBridge.exe Information: 0 : 
[10500] 2019-04-14 13:46:26.558+02:00 [10500:070] [INFO] IdleStateTracker - SendSystemIdleStatusUpdateAsync sent isIdle = False 
[7112] [3020] dopus: UpdateString would have previously invalided PIDL for "D:\" 
[9324] PPLE [Informational] LIFECYCLE: OnSuspending

Greetings from still foggy Munich,
B

1 Like