Which folders do you have Opus set to show when you start it? Are they folders with SVN contents in? Are they network or local folders?
Are the SVN sites you're using public ones? If so can you provide the details of them?
My normal starting directory is on a local drive, and all the SVN files are in subdirectories of the starting directory. In previous troubleshooting, I tried using a link that went to a completely benign directory on the same drive, and also tried a link to a directory on another local drive. Both of those locked up as well, so it didn't seem related to the directory I was opening.
Both SVN sites require logins, so I guess they aren't exactly public. Neither requires a FBI background check though 
I'll do a quick backup, and try the new version now. Stand by.
Rusty
No joy on Opus 9.5.0.2. It's funny, but it almost seems like you have to ignore it for a few minutes before it will lock up. I swear, I could open Opus 100 times in a row, while doing everything else I can think of in the background, and it would work. Then, if I do something else for a few minutes, then come back to Opus, it locks up.
Since Tortoise 1.6.2 is still working fine, I'll just stick with that for now. Thanks for all the comments.
Rusty
Jon & I spent some more time looking into this problem last night, going through the TortoiseSVN source-code changes between 1.6.2 and 1.6.3, using the two debug-dumps that were sent in as a guide.
We're pretty sure that we've identified the problem in TortoiseSVN and it looks like it will be fairly easy for them to fix. I think Jon is going to mail the details to them.
I got an email from Jon as well, and will be eager to test a corrected version of Tortoise. I have to say that really impressed by the dedication you guys have when it comes to correcting problems, even when they aren't yours!
Thanks,
Rusty
Jonathan Potter just sent his patch for TortoiseSVN.
I've applied the patch in r17777, merged it back to the stable branch and started the build.
You can download a fresh nightly build from the stable branch from here:
http://nightlybuilds.tortoisesvn.net/1.6.x/win32/
in 2-3 hours.
Note: the nightly builds from the stable branch are what will become the next release. No new features are added there to prevent introducing new bugs. Only bugfixes are applied there. So there's little risk in using that nightly build (despite of its name "nightly build").
The discussion thread about this patch can be found here:
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2426141
Many thanks for letting us know and the quick response integrating the patch!
(And for Tortoise in general!)
Thanks very much for all the excellent work that's gone into this problem. Jon in particular should win some sort of customer service award 
I'll give the new version a try in the morning, and report back.
Cheers,
Rusty
I tried the latest 1.6.6.17778 build, and I'm sorry to report that it locks up Opus just like the stock 1.6.6 version. I saved the dump files, and can send them to the Tortoise guys if they want them.
Thanks,
Rusty
13brv3 (at) bellsouth (dot) net
Did you restart after installing the TortoiseSVN nightly build? Without a restart, the old shell extension dll is still in memory and used by explorer and the desktop process.
Yes, I rebooted immediately after the installation, as instructed by the software. Still running perfectly with 1.6.2.
Thanks,
Rusty
This is all second-hand information so apologies if I make any mistakes. I thought it might be useful to pass on what I heard:
Jon mentioned that he made another test version which removed the shell-folder-lookup code completely so that it was like 1.6.2 in that area. (i.e. Removed the code which was moved around in the patch.) That version worked okay on Rusty's machine.
The version based on the patch, which still fails on Rusty's machine, seemed to work okay on the machine of another user who was having problems before. But Rusty mentioned that while the crash still happened it happened less often. so perhaps the second tester didn't use TortoiseSVN as much or in the same way.
It's possible there's something else on Rusty's machine which is perturbing things but the crash dump for the patched version apparently shows a memory corruption around the code accessing the critical section in the patched area, which seems like too much of a coincidence. (This is different to the original crash dump which showed a deadlock over a pair of critical sections.)
I changed TSVN so that the code which the suspect in causing the deadlock is moved to the class constructor. That way it's only executed once on startup and never again.
Could you please try the new nightly build from here:
http://nightlybuilds.tortoisesvn.net/1.6.x/win32/
if you then still get lock ups then I have to assume it's not this part of the code that's responsible.
Thanks for the effort, but I just tried 17815, and it did the same thing that one of Jon's test versions did. When boot into windows, I get no icons, task bar, or anything else. The computer is not locked up, because I can call up task manager, and browse files from another networked computer. Eventually, I get a message that says explorer.exe is not responding.
I make sure and have a fresh image backup handy before trying these tests now, so I'm reimaged back to normal (1.6.2).
Thanks,
Rusty
Could you maybe send me a process dump? Just send it to
tortoisesvn at gmail dot com
Maybe I can find out why it's not responding...
I can send a dump file for the previous 17778 version problem, but the version (17815) I tried today won't allow me to use the machine, so I'm not sure I can get a dump log from it. It's also too late now, since I've imaged the computer back to normal.
Rusty
I only keep the debug symbols of the latest nightly build. So a dump from the previous version won't help.
You said that with the latest nightly build, you eventually get an error telling that explorer doesn't respond. But that means you should still be able to Ctrl-Alt-Delete to get the task manager, select the explorer process and create a dump?
[quote="TortoiseSVN"]
You said that with the latest nightly build, you eventually get an error telling that explorer doesn't respond. But that means you should still be able to Ctrl-Alt-Delete to get the task manager, select the explorer process and create a dump?[/quote]
I've read that you can right click on a process and select the option to create a dump file, but I've never seen that option. There's a grayed out "debug" option, but perhaps this changes if the process is not responding? Keep in mind that my software skills are pretty much limited to double clicking the icon to run a program 
Cheers,
Rusty
The option "debug" is only enabled (not grayed out) if you actually have a debugger installed. You could install the Windows debugging tools to get one.
http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx
The "create dump file" menu is only available on Vista and later. But you might be able to use the second way described here:
http://support.microsoft.com/kb/931673
Thanks for the debug info. At this point, I'd have to say that loading the debug tools, and fiddling with that stuff exceeds my level of commitment to a solution. For the moment, I'm working fine with Opus and v1.6.2 of Tortoise, which is fine for my elementary SVN usage.
If I ever need to move to the latest Tortoise, I can always stop using Opus if the two still don't play well on my machine.
Thanks for all your help.
Rusty