BRS.EXE from Cyberling conflict with installers

[downscc]

This correlation continues.  Couatl hot update followed by two CTD events within several hours with fault module listed as stackhash_ae77.

I downloaded the complete GSX installer after the first crash and was rewarded with another crash a few hours later.

I'm looking for a reason why my system does not like your updates.  One thing I noticed is that every time couatl updates, it says it has to close an application that is running: brs.exe.  The brs.exe module is a Cyberlink module unrelated to flight simulation, and I have the Cyberlink software to provide monitoring of my Corsair liquid cooler and power supply.  Why do you kill this process?  Do you think it is related to the events?

Just for grins, I'll start rebooting after each time the updater does its thing and you take a look at this need to kill and unrelated process. Thank you.

EDIT:  Not related to Corsair but CyberLink is the user software and drivers for the BlueRay DVD installed in my workstation. Their product is also known as PowerDVD.

EDIT:  Ruled out brs.exe by rebooting and observing a CTD within an hour. Faulting module stackhash_6614 exception code c0000374. Next I'll turn off couatl engine in the exe.xml and give it another try.

EDIT:  Convinced it is couatl.exe because with it turned off, not loaded by exe.xml, there is no crash.  I've read that the stackhash becomes faulting module name when the OS looks at an address for module and doesn't find it.  Also read that DEP errors can be a source.  I had DEP turned on for only windows programs and modules, I changed that to turned on for all except and added couatl.exe to the DEP exception list.  Will run a session tomorrow after 1700Z to see if that helps.  Note mentioned earlier: Win10  P3Dv3.4 most FSDT and all Flightbeam products, AS16, PMDG B744v3.

EDIT:  Turned couatl back on in the exe.xml, downloaded latest addon manager installer and ran it.  When it said it had to close brs I declined and continued with the installation.  Now 5 hr into a session without CTD I suspect my problem is your installer interacting with an executable that has no relationship with your product.

Recommendation:  Evaluate why your installer thinks the CyberLink module brs.exe is using files that your installer wants to update.
  

[virtuali]

I suspect my problem is your installer interacting with an executable that has no relationship with your product

Our installer doesn't know anything about that product, and it doesn't interact with it, at all. I never heard of it before...The installer checks ONLY for these two executables, alerting you must close them before continuing:

- The flight sim .EXE file (either FSX.EXE or Prepar3D.EXE )

- The COUATL.EXE file

We, of course, haven't coded any of this, other than providing the standard installer program we use ( Inno Setup ) with the names of these two executables, so the installer will checks with the OS, which files are still being kept open/locked by any of them, giving a warning if it finds that files belonging to them are still open, in order to prevent people from mistakenly trying to start the installer when the sim is still running.

So, the real issue is NOT that our installer interacts with something it shouldn't, because it obviously doesn't but, instead, why this brs.exe is ITSELF interacting with FSX, up to a point that a standard installer routine would identify it as being the real FSX itself ?

The reason is probably related to a very questionable, invasive, and potentially dangerous practice of several products that use Hotkeys, doing what is called a Global Hook, catching each and every Windows message coming from all application, for the only reason to have their hotkeys available even if their application doesn't have the focus. Depending how they do it, this might possibly appear AS IF the BRS.EXE has opened files/handle/resources that BELONG to FSX.

So, what's really happening, and what you should really ask yourself, is not that our installer is interacting with something unrelated to it, but why THIS software you use, is interacting with *everything*, in a way so invasive, that it can attach to every executable in the system, including the simulator executable, enough to fool what is a standard feature of the installer, to believe FSX is still running.

It's likely you won't get this warning anymore, if you disable every function in that program that deals with Hotkey shortcuts.

[downscc]

That gives me some insight into why your installer asks to close brs.exe.

It is interesting that brs.exe is not an application but runs in the background and handles world regions for the DVD player, has something to do with playback restrictions based on country.  Brs.exe has no UI, it is launched by another exe that is the PowerDVD application for burning and playing discs. I've never used it on my machine, although I intend to burn some M-drives as soon as my taxes are done. I'll check for things like hot keys.

It is also interesting that your installer is the only one I've run that asks to close brs.exe.

OBTW I've had several sessions without CTD events so I'm convinced I've found how to avoid them by ignoring the installer request to close brs.

EDIT:  Just had a CTD event.  The 5th since the 13 Feb couatl update.  Still a stackhash, no module. Well, at least we now know the interaction between installer and brs.exe is a red herring.

[virtuali]

It is also interesting that your installer is the only one I've run that asks to close brs.exe.

I think I found a possible reason: searching the internet, indicates BRS.EXE requires MSVCR71.DLL, which is part of the MS VC++ runtime libraries.

This is also required by the Esellerate .DLL, so we need to install it too, in case the user doesn't have it already, or in case the user has an *outdated* version.

Our installer use versioning (again, it's automatically handled by the installer), so it won't ever overwrite any newer version it eventually finds in your system but, if this BRS.EXE came with an outdated version, and is also constantly running in the background, this might be the reason why the installer is trying to close it: it's locking an outdated version of the MSVCR71.DLL from being installed, because is still running and thus is preventing it from being updated.

[downscc]

Thank you for that update.  It doesn't seem to matter if I select close brs or not.

I discovered that if I select Couatl Live Update > Disable Addon during the session after departure and enable addon before arrival I do not experience CTD events.

[virtuali]

I discovered that if I select Couatl Live Update > Disable Addon during the session after departure and enable addon before arrival I do not experience CTD events.

That's even more strange but, it's possible it might be another entirely different issue, maybe related to a firewall or a similarly intrusive security-related product.

What the Live Update does, as the name implies, is to check for updates over the internet, and to some overzealous security products, this is enough to consider a program a trojan so, perhaps is attacking the parent process (Couatl.exe), making it crash.