Task Scheduler crashes Fluxfonts about fluxfonts

[da2x]

I’ve rebooted a couple of times just now, and I’ve yet to experience a crash. That could be a million things, but let us do a quick experiment.

Open Task Scheduler. Find Fluxfonts, right-click, and choose Properties. Go to Triggers and choose to edit the existing Trigger. Add a 5 minute delay to the start of the task. Does this make the crashes go away?

Are you using BitLocker, iSCSI drives, or something else that can cause unusual file system states?

[da2x]

Oh, those are silly defaults used in the Task Scheduler. The installer currently uses schtasks.exe, which doesn’t expose flags for changing the power policies. A COM approach is available to NSIS but it looks … unpleasant — and I’ve got really bad experiences with the PowerShell interface to Task Scheduler (much of what is exposed there hasn’t actually been implemented).

In conclusion: The Task Scheduler is great! Interfaces for working with the Task Scheduler are horrible. The installer for Windows needs reworking to setup a better longterm task for itself.

[da2x]

I’ve hibernated and restored a system with a debugging instance of fluxfonts a few thousand times now. I’ve yet to catch it crashing. (Though I do need to sort out the task scheduling issue too.)

[da2x]

I'd need more info to reproduce the problem. Are you low on disk space? Did the system hibernate? Do you have any software that might interfer with Fluxfonts files or operation (antivirus?)

Are you at all familiar with debugging in Visual Studio? If you could compile the project locally in Visual Studio, it could identify the problem easily.

Is Fluxfonts restarted by Task Scheduler after the crash?

I’ll leave fluxfonts running in Visual Studio for a few days, but I have yet to encounter any issues with the 2.0 release tag.

[spodermenpls]

I have 106 GB space left on my disk. I use the hibernation mode often times but it doesn't produce problems, except for non-deleted fonts in the folder sometimes. The crashes happened without interference from outside, during normal operation. There shouldn't be interference from Kaspersky Internet Security, I checked the logs and it didn't delete or block anything in the last 30 days. I already added Fluxfonts to the trustworthy programs with full access to the system, too.

I am not familiar with Visual Studio yet, but I should be able to get used to it. But I will need some time..

Yes, the Task Scheduler works. When I noticed the first time that Fluxfonts wasn't running anymore, I first thought that the scheduler didn't work anymore, but doing re-starts over and over again (with Fluxfonts starting) proved that wrong. The second crash, which I noticed just minutes after it happened, gave me the hint that the first "malfunction" must have been a crash too.

[spodermenpls]

I'm trying out the new Visual Studio 2017 Community version right now, but don't get much further than opening the "fluxfonts-2.0" folder and files, but not compiling it. I used to debug VBScripts and HTML back in the day, but not C programs.. could you give me some hints how to get it run? 😅
There might be a good chance that the problem is hidden way back somewhere, the last couple of days Fluxfonts was running without crashes (with standbys, re-starts and hibernations). It would probably increase the chances of identifying the bug (if there is one, and it's not a bug in Windows itself), if I would be looking into it as well.

[da2x]

Lets see, … . This should get you going (if not provide info about how far you get):

Open up the Visual Studio 2017 CE installer. Look for additional components and install clang.

Reset your local working directory, and try opening it in Visual studio again. That should let you compile fluxfonts. Change the profile from release to debug (in the main drop-down box in the main toolbar). If you then click the green run/build button than you should compile and run a local copy of fluxfonts. (Make sure to stop fluxfonts from the Task Scheduler first.)

If you encounter a crash or exception while running through Visual Studio, it will let you know by halting the program and displaying information about the problem. I need the information that appears when you run into the problem.

[spodermenpls]

Thanks for the "clang" advice, I hadn't installed that.
Instead of running Fluxfonts virtual out of the source code files, I found the "attach to a running process" tool, which I am running now with fluxfonts.exe. Is this the right tool to get valuable information you need if a crash occures?
Otherwise, you need to explain to me how to compile Fluxfonts in Visual Studio out of the lib-folder, I never used Visual Studio before, "resetting my directory" doesn't help me too much. 😅

[da2x]

Have you seen any more crashes? Did you manage to compile Fluxfonts in VS? If, not what errors do you get when you build it?

[spodermenpls]

Yes, another crash occured today, it happened shortly after a restart. The RAM consumption decreased below 500 KB from the start away (after an unusal session of increasing RAM up to 1 MB at the end).. do you think Fluxfonts could be unable to run its cycle if the RAM space sinks below a certain threshold?
I was able to compile Fluxfonts in VS, unfortunately I was not able to reproduce any problems there - seems to be a case of the demonstration effect. The crashes are fortunately rather rare, I created a shortcut in my Start Menu so I can quickly start if by hand if it happens. The need to check the Task Manager from time to time is not too convenient though.

[spodermenpls]

I am very certain that the crashes (I had two more) are correlating in some way to restarts. All the crashes I experienced, happened between 1 minute and 2 hours after a restart of Windows, once Fluxfonts runs longer than a couple of hours it becomes unlikely to suffer a crash. What could be Fluxfonts' problem? Unfortunately I can't simulate restarts with Visual Studio, to reproduce the crashes..

[spodermenpls]

Thanks for reminding me of the Task Scheduler (didn’t open it in probably 10 years), I think I found the reasons:
Fluxfonts was configured by default to only start if a power supply is attached and to shut down, when the power supply is disattached, and also to shut down after a run longer than 3 days. Using a laptop, this is of course doomed to fail. I went through all settings now and corrected them (also changed the set Vista to 10), this should do the trick. Are you able to correct the default settings of the Scheduled Task in Fluxfonts’ installer?

And no, I’m not using anything abnormal on my SSD drive, what could potentially bother Fluxfonts.

[spodermenpls]

Well, well.. seems like correcting the settings did not solve it. I had multiple new crashes with the following error code, displayed in the Task Scheduler: "The process terminated unexpectedly. (0x8007042B)". The hunt continues...

[spodermenpls]

I will re-install my Windows system when the Creators Update comes out, maybe that will solve things.

[da2x]

I’ve not been able to reproduce this in months on any of my systems. Do you still experience the problem?

[spodermenpls]

I didn’t have the chance to re-install Windows yet, that’s why I didn’t comment since.
Fluxfonts itself runs without problems, the automatic startup (by the Task Scheduler, despite having corrected the settings) is unfortunately still faulty. Started by hand, everything runs smooth, started automatically (after a restart), Fluxfonts starts with a reduced RAM consumption (0,4 MB instead of 0,7 MB) and crashes after a while. I avoid that by re-starting Fluxfonts by hand with every restart, which is rather inconvenient.

I will re-install my system in the near future and will report, if it solved the problem. If it wouldn’t, do you think it would be possible to run Fluxfonts as a Service, instead of relying on the crappy Task Scheduler?

[spodermenpls]

@da2x I finally found the time to install an all-new Windows 10 (Version 1709 - Fall Creators Update) on my system, but unfortunately it didn’t solve the issue of Fluxfonts crashing some time after a restart. Is there something left that can be done?

[Atavic]

Maybe a 3rd party program is blocking the startup of fluxfont, do you have other programs that start up automatically?

[spodermenpls]

@Atavic Fluxfonts does in fact start up, but crashes after some time (same issue as in November). Since it doesn't have a control panel, the only life sign I can measure is the RAM consumption, automatically started it uses 0.5 MB of RAM (and crashes), started by hand it uses 0.9 MB (and runs stable).
I suspected that Kaspersky Internet Security which I'm using might throttle Fluxfonts, but even with full access granted the issue stays the same. There are a couple of other programs that start up automatically as well, ETDTouch to make my touchpad work, Realtek Audio manager and Classic Start Menu, but I doubt these programs interfere with Fluxfonts.

[Atavic]

Yes, the culprit could be Kaspersky.

[spodermenpls]

@Atavic Kaspersky is granting Fluxfonts full access on the system, and even when I shut KIS down and disable the automatic start-up, the issue stays the same. Like I originally assumed (title of this thread), with the highest certainty the problem lies within Windows 10 (and its shitty Task Scheduler).

[spodermenpls]

I think I've solved the mystery: I've taken the Scheduler settings of another program, that runs without crashing, for Fluxfonts (start with User account instead of SYSTEM, start with login and not system start..) and so far I've haven't witnessed further crashes, when Fluxfonts started up automatically.

Résumé: the default Task Scheduler settings for Fluxfonts on Windows 10 are completely wrong and need lots of adjustment by hand. Case closed.

[da2x]

Here is the task scheduler task creation used by Fluxfonts:

fluxfonts/resources/nsis_installer.nsi

Lines 47 to 49 in 0b61bf7

	; Install scheduled task
	ExecWait '$SYSDIR\schtasks.exe /Create /tn ${PRODUCT} /sc onstart /tr "$INSTDIR\fluxfonts.exe" /ru SYSTEM /rl HIGHEST'
	ExecWait '$SYSDIR\schtasks.exe /Run /tn ${PRODUCT} /i'

Could you export your modified task scheduler task? or even better: suggest a patch to the schtasks.exe command used to create the task.

[spodermenpls]

Well, well.. mission failed after about 15 hours of runtime. I am running Fluxfonts as a service now (with NSSM: https://stackoverflow.com/questions/3582108/create-windows-service-from-executable/15719678#15719678), it works so far and should restart automatically now in case of a crash.

[spodermenpls]

After 1 ½ years it's time for an update:

Executing Fluxfonts as a Service is great, crashes - without an automated restart - are very rare (once or twice a year at max), more common is either the problem of Fluxfonts still running, but not creating new fonts, or it's creating new fonts, but doesn't delete any of the old ones (occurs maybe once a month, as I observe it via One Commander). Since it is run as a service - and not as a Scheduled Task - I can simply restart it via Task Manager's "Services" column, which provides a restart button after selecting "Fluxfonts" from the list. Even though the "Non-sucking service manager", which I still use for this, has a legendary name and works well (under Windows 10 2004, too, now), it hasn't seen maintenance since 2017 though and provides no further value besides this use case, so implementing Fluxfonts as a service natively might be the ideal scenario.