I've been able to reproduce the problem when moving fonts with 2 thumbnail threads.
I don't think the fault is in Opus (since it's a BSOD in win32.sys) but I'll send all these details to GPSoftware in case they can change something to avoid triggering the problem. e.g. Always generate font thumbnails on a single thread, perhaps.
Yeah, I think it's a windows bug somehow.
(Probably caused by some timing condition when freeing memory of similarly named fonts or something)
Hi, I'm new to the forum. I've been using dopus for several weeks now & I would never want to do without it! Thanks to GPsoftware for such a great product!
Anyway, I know this is kind of an old thread but I just wanted to report that I had the exact same thing happen to me yesterday when I was moving font files. I was organizing my fonts folder (not the system folder). I have the same system as the original poster (vista x64, quad core, 8 gb ram) & it crashed over & over with a bsod when copying a font that needed to be renamed. I'll change the thumbnail setting as described & hope it won't happen again because it really freaked me out!
Insha
I too have font copying problems limited to copying (drag and drop) from Copernic Desktop Search to a Dopus lister (Win XP, Win32). Never from directory to directory in Dopus or to other programs, just from Copernic to Dopus.
No BSOD, but Dopus blows up and dies by itself. Without Dopus alive it is impossible to work so I have to reboot.
I've only tried to recreate the conditions of failure so as to stay away and as close as I've gotten is that when Copernic search list overlaps with a Dopus lister I tend to have the problem. ("Tend" because it doesn't happen every time of course.)
I was going to write to ask if there is a shortcut I can use to restart Dopus without having to reboot every time but thought I'd try to get more facts first. The normal shortcut doesn't work because some parts of Dopus show up missing...
If you can't restart Opus after such a crash it's probably because dopus.exe is still running. Try ending it using Task Manager.
Though this font problem seems to be a graphics driver bug so it could be that dopus.exe is hanging waiting for the graphics driver to respond, in which case Windows may not let you end the process.
Can't get it to fail when we're all looking, of course. The Dopus icon on the lower right disappears when this happens. I'll try Task Mgr and see.
My cat is bigger than your cat!
The font crash is being looked into for the next Opus release. Can't promise anything as it definitely seems to be a graphics driver bug -- can't reproduce it in a virtual machine, for example -- but we have some ideas to try for a workaround.
Correction: Seems to be a Windows/GDI bug rather than a graphics-card driver one. After more investigation I can instantly reproduce the problem on both NVidia and ATI powered machines. Now that it's easy to reproduce it should be easy to test different fixes/theories.
The same problem seems to crop up in a few other programs as well but the way Opus deals with thumbnails and threads means it's a lot more likely to trigger the problem than most programs.
It should also be easy to produce a small, simple piece of code that will help Microsoft repro the problem and fix it but since that could take a while it's still worth adding a workaround to Opus for the time being.
EDIT/UPDATE: This issue should be resolved in Opus 9.1.2.0. It's a bug in Windows/GDI but a workaround has been added.
Just thought I would ad my 2 cents to let you know that you are not alone. It is a duplicable error. I do not have Dopus set as my default file manager and this problem does not occur with windows explorer. The majority of my moves have been made from a SATA internal drive to an external RAID via firewire800. Although it does not matter where I move the fonts. The blue screen still occurs.
I am using windows Vista Ultimate 32bit with 4 gigs of Ram on an Intel s3200 server motherboard with a Xeon quad core. I am organizing and managing in excess of 80 thousand fonts so I am anticpating the update. 
The 9.1.2.0 update has been out for a week already. 
(It may not be detected by the update checker yet, though. See here for why.)
Trying to drag and drop (font) from Everything to Directory Opus. Consistently get a fatal error (DOpus dies) when mouse is released. This message came up copying single file (.ttf) to open directory. Error 0xc0000005 in Thread 0xc64 at 0x8B5EEB1C
DO 9.1.3.0.3449.x86
[quote]Trying to drag and drop (font) from Everything to Directory Opus. Consistently get a fatal error (DOpus dies) when mouse is released. This message came up copying single file (.ttf) to open directory. Error 0xc0000005 in Thread 0xc64 at 0x8B5EEB1C
DO 9.1.3.0.3449.x86[/quote]
Sounds like an unrelated problem if it's just taking out the process.
Does it only happen with font files?
Does it happen if you drop the same files from other programs, or only when Everything is the source of the drop?
Is the lister in thumbnails mode? (If so, does it happen when not in thumbnails mode? I'm wondering if the crash is due to the drag & drop or due to the font thumbnail generation.)
Are the fonts large in size or being copied from slow media? (Perhaps the font-drawing code crashes if it tries to thumbnail an incomplete file.)
I had this same problem using Copernic search moving font files into DOpus listers as noted above. I don''t use thumbnails.
I deal only in fonts so don't know what happens for other file types.
This was a complete font. Medium size 79kb, kinda old but still fully functonal (SlimPickensCapsSSi.ttf).
Dbl clicks into font viewer work correctly. Drops into other apps ok also.
No help. Sorry
If the crash happens all the time could you quickly try with a different type of file so we can narrow down what we have to look for?
Which columns are shown in the file display? Anything like Font Name or Description which would cause Opus to look inside the file right after it was created?
I've been successful in image files: gif, bmp, jpg, tif.
Been unsuccessful in ttf, otf, pfm, pfb fonts.
I had no problems copying these same files into Windows Explorer.
Lister columns are (file) Name, Size, (file) Type, Modified date/time, Attribute, Dimensions, Shooting time. (Last two are blank on font files). From Everything the visible columns are: (file or directory) Name, (full) Path, Size, Date Modified.
Some background: in XP (at least), there are excessively long delays when handling font files. Apparently each file in a directory has to be read, (installed?), and decoded. DOpus doesn't do that so is incredibly much faster handling fonts. (Seems as fast as any other file type). This was the reason I purchased DOpus in fact.
You can see this slug action in any program that accesses a directory containing fonts (not using DOpus). I wonder if there's any conflict gong on there?
During my testing, I frequently got this error "Access violation at address 03E23776 in module IZArcCM.dll Read of address 00000004" and this one:
Can you try using ShellExView to disable all the shell extensions with type Drag & Drop Handler and Drop Handler?
If that stops the problem, enable a few until it comes back to see if you can narrow it down to a particular handler.
I'd focus on the IZArc handler(s) first, since they're mentioned in one of the crash messages, but they could be an innocent bystandarder so don't assume it's definitely IZArc yet. You may find that disabling IZArc means a different handler starts to crash, because some other handler (or Opus itself, potentially) is corrupting memory and causing anything that is used after it to crash.
Once you're done you can enabling everything again using ShellExView.
Are you dropping with the left or the right button?
Am dropping with the left button. (I'm left handed...)
Umm.. ok.. sorry, just to clarify - by your "I'm left handed" comment do you mean to say you have switched your mouse buttons around?
When I asked which button you were dropping with it was an attempt to elucidate whether you are performing the drag and drop action that results in an immediate file copy, or one that results in a popup menu being displayed. It wasn't an anatomical enquiry.
(Normal mouse setup. Abnormal user setup.)
I used ShellExView successfully (SURPRISE).
Disabled IZARC DragDrop Menu (Drag & Drop Handler) as you suggested. Problem seems to have gone away. Really! In the few number of tests (10) I couldn't make it fail!! Oh, joy!!
Thank you all.