We use TortoiseSVN a lot ourselves and have not run into any problems lately.
Of course, there may be a problem that is only triggered with certain combinations of actions or files. But, especially with what looks like a memory corruption issue, it's possible TortoiseSVN is not the real cause, but it being loaded moves other modules around such that things are lined up in the right way for the crash to happen.
Do you see the same crash if you disable most shell extensions except TortoiseSVN?
If you have the Windows debugging tools installed (specifically, gflags.exe), I can suggest some tests you can do which may locate the problem more exactly. You can switch into a mode where Windows does vigorous testing of the memory heaps after each operation, and will detect problems (usually) the moment they happen, instead of the moment something slips over the banana left by something else a few moments later. The process runs slower, but it means you can generate a crash dump which may point to the exact cause.
The debugging tools are an optional install, but if you're using TortoiseSVN for Windows development then you may already have them. If so, here are the commands, in case they are useful.
They need to be run from an Administrator command prompt.
-
Turn on PageHeap debugging, the next time dopus.exe is launched:
"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\gflags.exe" -p /enable dopus.exe /full /protectAfter turning it on, fully exiting Opus (via File / Exit Directory Opus), then re-launch it and see if you can trigger the crash. If you can, collect the crash dump as before.
Opus will run much slower while it is on.
-
Turn off PageHeap debugging and return to normal, the next time dopus.exe is launched:
"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\gflags.exe" -p /disable dopus.exeAs with turning it on, fully exit Opus, then re-launch it. Speed should return to normal.