Nasty crashes - font related

Help & Support
1

[Admin note: This issue should be resolved in Opus 9.1.2.0. It's a bug in Windows/GDI but a workaround has been added.]

Been getting nasty windows crashes(bsod) for some time now...
Always while moving lots of fonts fast.(for some odd reason copying them or deleting them never triggers the issue.

I was wondering if anyone else had gotten the issue...
(windows vista x64 here, on a quad core with 8GB of ram)
I checked memory, gpu, cpu, and hdds extensively but without any hint of any problem ever...

[code]
0: kd> !analyze -v

  •                                                                         *

  •                    Bugcheck Analysis                                    *

  •                                                                         *

SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff96000103bcc, Address of the exception record for the exception that caused the bugcheck
Arg3: fffffa6004df1fe0, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.

Debugging Details:

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

FAULTING_IP:
win32k!PFEOBJ::vFreepfdg+e8
fffff960`00103bcc 0fba60300f bt dword ptr [rax+30h],0Fh

CONTEXT: fffffa6004df1fe0 -- (.cxr 0xfffffa6004df1fe0)
rax=0000000000000000 rbx=0000000000000000 rcx=fffff900c6003410
rdx=00000000000007ff rsi=fffff900c5fbfe60 rdi=fffffa6004df28c0
rip=fffff96000103bcc rsp=fffffa6004df2840 rbp=0000000000000001
r8=000000005e2d7e0a r9=0000000000019c99 r10=000000000000f02a
r11=fffffa800c989ac0 r12=0000000000000000 r13=fffff900c4181030
r14=0000000005444150 r15=0000000000000001
iopl=0 nv up ei pl nz na po cy
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010207
win32k!PFEOBJ::vFreepfdg+0xe8:
fffff96000103bcc 0fba60300f bt dword ptr [rax+30h],0Fh ds:002b:0000000000000030=????????
Resetting default scope

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP

BUGCHECK_STR: 0x3B

PROCESS_NAME: dopus.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff960002b106a to fffff96000103bcc

STACK_TEXT:
fffffa6004df2840 fffff960002b106a : 0000000000000000 0000000000000000 0000000000000000 fffff960001408c5 : win32k!PFEOBJ::vFreepfdg+0xe8
fffffa6004df2870 fffff960002bb81b : fffff900c6003410 0000000000000001 fffffa6004df2950 0000000000000000 : win32k!RFONTOBJ::vDeleteRFONT+0x32
fffffa6004df28c0 fffff960002bb492 : 0000000000000000 fffff900c42d5ca0 fffff900c0646ca0 fffff900c403f550 : win32k!vRestartKillRFONTList+0xab
fffffa6004df2910 fffff9600023fb62 : fffffa8008896f90 0000000000000001 0000000000000000 fffff90000000005 : win32k!PFTOBJ::bUnloadWorkhorse+0x196
fffffa6004df2990 fffff96000262431 : fffff900c50f4940 fffffa6004df2ca0 0000000000000000 0000000000000000 : win32k!GreRemoveFontResourceW+0xea
fffffa6004df2a00 fffff80002a65df3 : fffff8800c41a090 fffffa800c989ac0 00000000000014b0 fffff80002ce2ec4 : win32k!NtGdiRemoveFontResourceW+0x1c5
fffffa6004df2bb0 000007fefec1069a : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13
000000000bd5f3a8 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x7fe`fec1069a

FOLLOWUP_IP:
win32k!PFEOBJ::vFreepfdg+e8
fffff960`00103bcc 0fba60300f bt dword ptr [rax+30h],0Fh

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: win32k!PFEOBJ::vFreepfdg+e8

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: win32k

IMAGE_NAME: win32k.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 48d1bca9

STACK_COMMAND: .cxr 0xfffffa6004df1fe0 ; kb

FAILURE_BUCKET_ID: X64_0x3B_win32k!PFEOBJ::vFreepfdg+e8

BUCKET_ID: X64_0x3B_win32k!PFEOBJ::vFreepfdg+e8

Followup: MachineOwner

0: kd> lmvm win32k
start end module name
fffff960000a0000 fffff96000351000 win32k (pdb symbols) c:\symbols\win32k.pdb\42BB19DFC615435E8ADEF3DBDDD06AC02\win32k.pdb
Loaded symbol image file: win32k.sys
Mapped memory image file: c:\symbols\win32k.sys\48D1BCA92b1000\win32k.sys
Image path: win32k.sys
Image name: win32k.sys
Timestamp: Thu Sep 18 04:27:53 2008 (48D1BCA9)
CheckSum: 002AAB81
ImageSize: 002B1000
File version: 6.0.6001.18145
Product version: 6.0.6001.18145
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 3.7 Driver
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: Microsoft� Windows� Operating System
InternalName: win32k.sys
OriginalFilename: win32k.sys
ProductVersion: 6.0.6001.18145
FileVersion: 6.0.6001.18145 (vistasp1_gdr.080917-1612)
FileDescription: Multi-User Win32 Driver
LegalCopyright: � Microsoft Corporation. All rights reserved.
0: kd> .cxr 0xfffffa6004df1fe0
rax=0000000000000000 rbx=0000000000000000 rcx=fffff900c6003410
rdx=00000000000007ff rsi=fffff900c5fbfe60 rdi=fffffa6004df28c0
rip=fffff96000103bcc rsp=fffffa6004df2840 rbp=0000000000000001
r8=000000005e2d7e0a r9=0000000000019c99 r10=000000000000f02a
r11=fffffa800c989ac0 r12=0000000000000000 r13=fffff900c4181030
r14=0000000005444150 r15=0000000000000001
iopl=0 nv up ei pl nz na po cy
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010207
win32k!PFEOBJ::vFreepfdg+0xe8:
fffff96000103bcc 0fba60300f bt dword ptr [rax+30h],0Fh ds:002b:0000000000000030=????????[/code]

2

Note: I have had multiple occurrences of that very same crash always crashing in dopus.exe.
(half a dozen of them today, since I was working on some fonts)

3

Where are the fonts being moved from and to? The standard fonts folder or other locations?

If you are moving into the system fonts folder then that is wrong as you should use Copy INSTALLFONT which will register the fonts with Windows.

Moving fonts out of the system fonts folder could also cause problems since they should be unregistered before being deleted.

Neither should cause a crash though...

Does the same crash happen if you perform the same operation in Explorer instead of Opus?

If the standard fonts folder is the source or destination, how is it displayed in Opus? Like all other normal folders in Opus, or like a folder in Explorer and the My Computer folder in Opus? (This depends on your "treat folders as virtual" settings in Opus.)

Depending on the view mode and/or columns shown (plus other things like shell extensions, e.g. ones which display overlaid images on file icons and are potentially called for all files), it could be that something is crashing when it tries to extract information from a half-written font file. The FAQ on general slowdown or instability investigation steps contains various ideas that may help narrow down the cause of the problem.

Also see if it only happens with certain font files or certain types of font files. If it does, zip some up for other people to test moving the same files between the same types of folders. (If it seems to happen with any font files then there's no need to create a zip, of course.) If the problem happens for everyone then it should be easy to pinpoint and fix. If it only happens on your machine then it's probably due to a 3rd party component which can make things trickier.

4

Sorry, I didn't realise this was a BSOD crash until I re-read... Those can only be caused by the OS or drivers (which can include low-level things like virus checkers, virtual disk tools like TrueCrypt/DaemonTools, DRM systems for games, etc. as well as the more obvious graphics, sound and motherboard drivers). So the trigger could be a number of things but the bug itself will probably be driver related, unless it's a bug in Windows itself.

I would check that your graphics drivers are up-to-date in particular, as they are most likely to be involved with fonts. If that doesn't help, try disabling any real-time anti-virus scanner to see if the problem then goes away.

Also, these threads found by searching Google for vDeleteRFONT BSOD may be of help:

bleepingcomputer.com/forums/topic179422.html

bleepingcomputer.com/forums/topic181578.html

5

There's no font installing/uninstalling involved, just moving them from a normal folder to another.
Display mode always was detail.(I dont use anything else)

And I had checked those threads before.

The list of loaded drivers show nothing specials either, and there should be no malware/virus... So this has puzzled me.
The whole thing is very odd and has me quite confused about what could cause it.

6

Oh and I could not find any specific font causing it.
The only thing causing it seems to be some timing conditions related to moving a lot of fonts very fast.

7

Does it happen if you move them with Explorer?

8

Not that I could see.(it's not exactly easy to trigger that crash...)

The one thing I'm thinking is that the only thing that could be causing it to crash is that when moving them the copy windows shows icons changing at high speed and maybe something goes wrong with some cache-ing in windows there.

Was there any way to not display any icon in the copy window?

9

Turning off the "progress bar speed timer" option will stop the icons being shown. (The option means you see the minimal progress window instead of the big one.) It's under Preferences - File Operations - Progress Indicators.

10

I have just figured a probable part of it:

1.it seems(I think) to occur as it is trying to display a confirm file replace dialogue, where it actually disaplays a render of the font.(any way to change it so it does not display any icon/preview there?)
2.it might have to do with a singular situation where 2 files with the same filename but different case coexist on an ntfs drive...

11

There's no way to disable that but you could avoid the Replace dialog by making a copy command with the choice hardcoded. For example,

Copy WHENEXISTS=replace

Have you got NTFS configured as case-sensitive? That would be unusual and break a lot of Windows apps. (It is an option for Windows file servers that need to behave like Unix but it's very rarely used.)

12

Sadly I just had a crash again, and there's no duplicate filename with different case.(I actually fixed all of those, and made sure that the linux smbs that access the shares I'm working are made case insensitive)

(And case sensitivity is not an ntfs switch afaik, ntfs is case sensitive, it's just almost every single application in windows is case insensitive, set aside for window's nfs & cifs servers)

So back to the drawing board...

I am going to try to tell dopus to use only generic icons. Hopefully that'll not crash...

13

And just had it again, this time it was almost a testcase.
One folder with a ttf font open in dopus.
I copy that font on the desktop
then I try to copy it back in the original folder.
At the instant where the replace dialogue should have appeared it crashed.

Any way to disable font previews at all?

14

No way to disable them. Have you checked your graphics drivers are up-to-date?

15

Tried 3 different versions.
(nvidia 180.x, 185.x, 178.x)
Same results.

I have been progressively disabling services&drivers, and hopefully whenever things are stable I should find who's the culprit.

16

Do you get the same crash if you go into thumbnails mode in the source and/or destination folders? That should also cause the fonts to be displayed in a very similar way. Might speed up your search at least.

(You should turn off thumbnail caching and empty the cache to ensure the thumbnails are generated each time you refresh.)

17

Did not get it in thumbnails.
I have not gotten the crash in hours though now and been working on a lot of font work.

Last things I did were: 1.change dopus thumbnail generation from multi thread to single thread 2.stop the process pacifier service.

So I'd guess it's one of those or both.

18

Process Pacifier installs a driver to catch process startup so it's quite possible it could cause a BSOD. (Indeed, its change log mentions one BSOD that was fixed in the past.)

19

I... actually disabled process pacifier for nothing. It had nothing to do with the crashes as far as I can see.

So today I decide to change back the number of thumbnail threads from 1 to 4.
I got a nice crash within 5 minutes of changing that... while I had been moving fonts with no crash for hours.

So I can say with pretty high certainty that it's directly linked to the number of rendering threads.

20

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.