Fail Fast Exception

Hi Fred,

I am working in administrativ context and hence also does PI. UAT is disabled. Hence PI has the privelages to start the service very well.

Moreover, for me as an user, it makes no difference if the PI core app starts the service or the used QT frame work. It is the program “Pixinsight” from users point of view. And this does definitely something strange and if the used QT frame work acts wired or is buggy, it needs fixing or updating, since it is actually triggering some unintended action. Moreover WERS is deactivated for privacy reason intentionally, so it is definitely not acceptable, if an application is modifying the OS configuration, especially if not required to work. I really dislike it, if applications punch holes into a security resp. privacy concepts. I consider this as a serious bug, regardless what part (core or 3rd party components) cause this behavior.

As described: when service is set to manual it gets started when closing PI. If it is set to disabled, the error is thrown, since the service can not not be started by PI on exit. This behavior is reproduce able.
 
It may be reproducable for you, but I've never seen it. I'm just another user, but I doubt if the PI team can do anything without some more specific context - what is different between your system and the thousands of Windows users (like me) who don't have the problem. There is clearly either something wrong with your system (most likely in my opinion), or something unusual about your system (e.g. unusual display / processor / storage hardware) with some incompatibility with the PI software. If you can't guess what, I don't see how anyone else is going to be able to guess.
If you run dxdiag and post the log file, then at least folks could think about the hardware configuration.
 
Hi Fred,
there are multiple identical reports. As you see here in the forum, but also completely different applications. This is a very well know error caused by QT framework. Not only PI is affected. Users who run any application with that specific QT version and having WERS disabled get this error. You find many error reports in the applications specific support areas.
To summarize: This is neither an individual case, nor an unknown error, nor is something wrong with my system. This is very well known and documented issue. This needs in the simplest case updating QT, or changing the application exit method, so far I had understood from he technical documentations.

Addendum:
see example below. Completely different application, but identical error and identical workaround. https://bugs.launchpad.net/calibre/+bug/1869713
 
Last edited:
Moreover, for me as an user, it makes no difference if the PI core app starts the service or the used QT frame work. It is the program “Pixinsight” from users point of view.
Click to expand...
it is definitely not acceptable, if an application is modifying the OS configuration
Click to expand...

Neither PixInsight nor Qt can enable or disable Windows Error Reports. Period.

I am working in administrativ context and hence also does PI. UAT is disabled.
Click to expand...

I assume you refer to UAC (User Access Control). This is wrong and extremely dangerous practice. A complex application with a huge attack surface such as PixInsight must never, ever be executed with administrative privileges on any operating system, and very especially on Windows for quite obvious reasons. Do that at your own risk. These are not normal working conditions.

This is a very well know error caused by QT framework.
Click to expand...

AFAIK, there are no official Qt bug reports to substantiate that affirmation. I'll ask Qt support (time permitting, as I have many much more urgent ongoing tasks) but I doubt this can be confirmed. Most likely this is a rare interaction between our Chromium web browser component (QtWebEngine) and a combination of third party software components, probably involving a graphics driver. This cannot be reproduced under normal working conditions and is completely out of our control and scope. This cannot be accepted as a bug in PixInsight, at least with the information provided.
 
As always happens with bug reports, we need a repeatable pattern to reproduce and understand a problem under normal working conditions in a consistent way. In this case this is unlikely because the preconditions that you are describing are definitely not normal for execution of an application like PixInsight, and there is no code at all in PixInsight able to do what you are describing (alter system configuration settings).

At any rate I strongly recommend that you never execute PixInsight (or any other userland application for that matter) with administrative privileges. There is no valid reason to operate a modern system as an administrator (i.e. with root privileges) on a regular basis. Doing that is just calling for severe issues.
 
I have created a new user profile without any administrative rights and logged in. Simple User land, fresh and unspoiled.

The WERS is deactivated.

1. Start PI (double click Icon)
2. It is asking for registration
3. Hit "Cancel", PI window gets closed and immediately the
4. "Fail Fast Exception" is thrown

It is not required to do any action within PI itself. Just closing the application. The exit event triggers the error. This is reliably repeatable.

What I can see what happens so far:

Syndrom:
1. PI gets closed and QTWebEngine fires "Fast Fail"
2.a. If WERS is deactivated, the "Fail Fast Exception" is fired since WERS could be started by Windows itself
2.b. If WERS in in manual start mode, it gets started and the FastFail function is excuted without any Exception

Privileges
User privileges do not play any role since WERS runs in System context of collective service svchost.exe and is also triggered by Windows and not user.

Root cause:
I agree, that it is very likely, as you pointed out, that there is a problem between QTWebEngine and some other component on exit (e.g. graphics driver which I have also updated for test). The problem is actually that the "Fail Fast" is fired which will raise the Exception when WERS is deactivated. But this is a pure QT topic they have to handle. Hence I am quite convinced it will be gone in one of the next releases - if not already.

Conclusion:
Since this error has no functional impact I can wait for the next update(s). Probably it will be gone there.
So lets wait and see. So no need for further investigation.

Cheers
Rüdiger
 
Last edited:
Hi Juan, Hi Fred,

thanks for fixing it in 1.8.8-9. Now the error is gone, though "there was none".

Cheers
Rüdiger
 
You must log in or register to reply here.
Back
Top