we use Deadline & Cinema4D+RS for rendering. Everytime when a machine in our network starts a new task, the windowsexplorer.exe crashes. This means when there is only 1 frame per task, it crashes every minute (depends on the scene) and so working along the way is not possible when the machine is rendering, because every window or program closes with each new task.
At least we found out, that this problem stays in touch with the Font Sync from Deadline. Due to every task-start we had the slave syncing the fonts, just to be sure that every slave has all fonts.
When we are changing the font sync to just one time when the slave starts, then the windowsexplorer.exe crash has gone. Is there a minor update to change this issue ?
I can remember a late Deadline 9.X version, where this problem wasn´t there.
I currenlty have this error too (when font Sync is on for PC) windows 10 deadline 10.1.9.2. We are rendering with maya 2018.4 and redshift 3.0.05. Windows explorer crashes on every task.
we still have the issue, even with new windows versions and with the current deadline version.
We did a work around and activated the fontsync only on start of the slave. So if you insert a new font into your sync folder, you need to restard all slaves. However, this is done pretty quick, so we didn’t invest a lot of time to look for a fix.
Eamsler,
I am seeing this problem. I was doing C4D 2023 on my workstation via deadline 10.2.0.10 and noticed explore reloads for every render task. I guess our farm has been having the problem all along but it was much more annoying this time since I was trying to work while rendering on my workstation.
This is on both windows 10 22H2 and Windows 11 22H2. If fontsync is disabled, the problem goes away. I ended up doing what kontakt suggested and having it run on worker startup to minimize the issue. But it would be nice to have this issue fixed properly if possible.
Thanks for the update on this, I have updated our internal ticket to engineering team with the recent data and that you are able to still reproduce it on latest Windows version.
I cannot tell an ETA on the fix though.
I did some digging into this today and frankly, I’m not quite sure what we can do about this. The code we have inside Deadline that’s leading to this crash is extremely simple. Here’s the whole of it:
public static bool RegisterFonts( string[] fontFileNames, int millisecondTimeout )
{
#if WINDOWS
int registeredCount = 0;
foreach( string fontFileName in fontFileNames )
registeredCount += Gdi32.AddFontResource( fontFileName );
// Send a notification that fonts have changed (if any were actually installed).
if( registeredCount > 0 )
{
uint delay = (uint) millisecondTimeout;
int result = User32.SendMessageTimeout( User32.GetHwndBroadcastAsIntPtr(), User32.WM_FONTCHANGE, IntPtr.Zero, 0, 0, delay );
if( result == 0 )
throw new Exception( "Registering fonts timed out. Try increasing the timeout value." );
return true;
}
#endif
return false;
}
I’m not sure if the broadcast message here is what’s killing Explorer or not. I found this example that doesn’t broadcast a message. Can you see if this works if you save it then run it either through a python installed on the system or via “C:\Program Files\Thinkbox\Deadline10\bin\dpython.exe”
import ctypes
def install_font(font_path):
# Load the AddFontResourceA function from the gdi32 library
addfont = ctypes.windll.gdi32.AddFontResourceA
# Call the AddFontResourceA function with the font path as the argument
result = addfont(font_path)
# Return True if the font was installed successfully, False otherwise
return result != 0
# Example usage
font_path = r"C:\Windows\Fonts\myfont.ttf"
result = install_font(font_path)
if result:
print("Font installed successfully")
else:
print("Font installation failed")
We’re passing SMTO_NORMAL (0x0000) when we ask all running applications to reload their font cache so I don’t think Explorer is dying because of that.
@eamsler,
Thanks for looking into this. The code sample you gave does not crash explorer… but I also could not get it to install a font. So I am not sure it was a fair test.
It returned false running as is.
If I tried to set a path to a font to test like C:\ftest\myfont.ttf, it also returned false.
Trying the font path shown in your code (C:Windows\Fonts\myfont.ttf) also returned false. But in that case, I had to put a font there for it to register, but by doing that, it already invoked installing it because I did it with the gui. So it might of failed because that font was already installed.
I think newer versions of windows (10 and 11) would not let you simply copy to that C:Windows\Fonts\folder via a script. I think deadline was copying to a temp folder and registering them temporarily for that login session.
I’m actually pretty sure it came in with UAC in Vista. The permissions on that folder are very restrictive (I believe some installer user). It was a fun surprise after Windows XP64.
The fact that the Python script didn’t work isn’t ideal. I have some other focused work I need to get off my plate but I could maybe take a look next week.
Further hacking on this, I’ve recreated registering fonts via Deadline font_register_deadline.py (344 Bytes) using "%deadline_path%"\deadlinecommand -executescript font_register_deadline.py.
But I’ve gotten a simpler script working as well that can register and broadcast without crashing explorer. font_register.py (957 Bytes) running either as above or with just python font_register.py.
Could anyone experiencing this explorer crash give the second script a spin to see if it’s all font broadcasts or just when Deadline triggers it?
I ran font_register.py with it altered to pick a font I had to install from c:\test\myfont.ttf
It did not make explorer flicker or crash. But it also did not actually install the font. The command prompt was elevated as an administrator. The message was as follows.
Font installation failed
Font broadcast successfully
I’m not sure why the font fails to install - I am a little worried that the broadcast only causes the flicker if there’s a new font to actually broadcast. At the very least we know that not all font update broadcasts knock over explorer.exe on your machines. You didn’t touch the inside of font_register.py right? If you didn’t then there’s no way it successfully registered a new font either.
If that’s the case I’ll take this back to the engineers that it’s 100% how we’re doing things that are causing strange behaviour.