Closed rippy65 closed 2 years ago
Hi @rippy65. What's the problem? That file looks file, and I'm not sure what error you're seeing? If there's a corruption problem installing BBL it should offer to raise a full error report with all the details filled in, so I'm not quite sure what problem you're having?
Well, the exe.xml isn't read (anymore9 by MSFS...the progs listed won't start automatically...
edit: according to these reorts it could also be a new bug with the latest msfs build: https://forums.flightsimulator.com/t/exe-xml-often-not-starting-addons-correctly/515592 ?
I've just put the exe.xml
file that you uploaded into my Flight Simulator installation and moved BetterBravoLights to the same location as you have it in. When I started up MSFS, BetterBravoLights and FSUIPC both ran successfully. So it doesn't appear to be a problem with the exe.xml
file itself?
I don't have AFCBridge, FS2Crew or MobileCompanion so my MSFS will be attempting to start those and just giving up. It's possible though that one of those might be causing issues? I'm making complete guesses but the MobileCompanion
entry looks a little odd, not pointing at an .exe
file?
Given that the file itself appears valid, and is working on my machine, it would be worth setting them all to be <Disabled>True</Disabled>
and changing that to False
one by one. (But don't enable both AFCBridge and BetterBravoLights as they'll fight over your Bravo!)
Are you using the Windows Store or Steam installation of MSFS and what's the exact filename of your exe.xml
file?
Thanks for these tips, will try them out in an hour or so,,,, WinStore Installation here, location of exe.xml is AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\exe. xml, which should be correct. ...
Yup, path looks correct.
I've just put some other suggestions (to do with encoding) on the forum posting you link to. The file you uploaded is a little odd as it says it's 1252 encoding but with a UTF8 byte-order-mark. Not the end of the world, but it's the sort but it's the sort of thing that can really mess with XML parsers. Having said that, of course, that file is working fine on my machine.
Anyway, as long as the GitHub upload process hasn't completely messed with that file, the fact that your exact file is working for me should be useful information and possibly point to one of the things mentioned in the file rather than the file itself?
Btw, for a few weeks I've been thinking about spinning a dedicated exe.xml
manager tool out of all the wacky installation code I had to write for BetterBravoLights. I've seen some insane stuff in exe.xml
files over the last year, absolutely trashed by some installers.
'Anyway, as long as the GitHub upload process hasn't completely messed with that file, the fact that your exact file is working for me should be useful information and possibly point to one of the things mentioned in the file rather than the file itself?'
I agree ;)
'Btw, for a few weeks I've been thinking about spinning a dedicated exe.xml manager tool out of all the wacky installation code I had to write for BetterBravoLights. I've seen some insane stuff in exe.xml files over the last year, absolutely trashed by some installers.'
That would be great. IMHO too many payware devs (cough') are coding rather .... lazy?π
Yes. Some of them are clearly not using real XML parsers and are just doing very bad search and replace. I had one user whose AFC Bridge had never worked since they got their Bravo (before I wrote BBL) and on looking at their exe.xml
file they had three RealSimGear entries at the start, only the first of which was valid enough for MSFS to do anything with, and the rest of the file was trash.
Hence BBL is super conservative about what it'll even try to modify, and how it preserves encodings, etc. Should be useful to see how this - and that forum post - pan out, as we should learn something more from it about how MSFS deals with exe.xml files. In the past I've seen it start up the first few things in the file that were valid, and ignore the rest. Despite the claims in that forum post that whitespace makes a difference, it's definitely previously 'kinda' worked with files that weren't even valid XML.
This gets strange..
I re-wrote the complete exe.xml in notepad++, it worked. Exactly ONCE. π€π
After MSFS shutdown and relaunch, it didn't work.
Setting all but FSUIPC to disabled=TRUE didn't help. It does not work. See rewritten file.
Anyway...I'm sending a small compensation for your will to help out...
Edit 1730 Zulu:
Stripped exe.xml down
`<?xml version="1.0" encoding="UTF-8"?>
It gets curiouser and curiouser... I don't understand why it would work once. The only thing I can think of that would cause that would be if, say, something you were starting up with MSFS was already still running from a previous run, but if the only thing you're running is FSUIPC that doesn't make sense. Each fresh MSFS startup should be independent of the last.
Thank you for the generous donation; totally unnecessary but very much appreciated!
I've just tried pasting in the one-liner exe.xml you posted above:
<?xml version="1.0" encoding="UTF-8"?> <SimBase.Document Type="SimConnect" version="1,0"> <Descr>Autolaunch</Descr> <Filename>exe.xml</Filename> <Disabled>False</Disabled> <Launch.Addon> <Name>FSUIPC7</Name> <Disabled>False</Disabled> <Path>C:\FSUIPC7\FSUIPC7.exe</Path> </Launch.Addon> </SimBase.Document>
and that works fine for me. It starts up FSUIPC happily.
I've tried your latest EXE2xml.txt
file. I pasted the contents of that into my exe.xml
file using Notepad++ works so it created a UTF8 file without a leading byte-order mark. Despite the slightly-dodgy-looking leading space before the first XML element that works fine.
I've also tried it directly, with the leading UTF-8 byte-order-marks from your original file. That all works fine too.
So as far as I can make out, all the things you're doing to your exe.xml
file should be fine, and my MSFS is happy with it. I think you're doing the right thing, stripping your exe.xml
file right down to just the one FSUIPC7 entry to diagnose it.
If I were you, I'd want to know whether MSFS is even trying to load FSUIPC. I'm not sure how technically-minded you are, but what I would do in your situation is to run a tool called 'procmon', available free from https://live.sysinternals.com/. If you want to give it a try, run procmon.exe
and use its filter screen to set a filter on 'Path contains FSUIPC', like this:
.
Once you've set that filter, the tool will then monitor all file and registry accesses looking for any attempt to open, read, write or delete any file with FSUIPC in the name, and show you what's happening. Warning: whilst it's running it will slow your computer down. When starting up MSFS you should hopefully see something like a thousand entries in procmon, something like this:
It can be a little hard to read some of that output. For instance, 'CreateFile' doesn't mean it's creating a file: it just means it's creating a file handle in the operating system, and some errors are completely normal.
Feel free to let it run, then hit File->Save and create a PML file and upload it here and I'll take a look. (Make sure you have the 'Events displayed using current filter' option selected in the save dialog!)
I'm still completely confused by the 'works once' thing. It would be interesting to see a PML trace of it working and a separate PML trace of it not working.
Royston,
thanks - yes, If I were a esoteric guy I would find the things happening with the xml spooky...π - Yesterday evening I even started the whole process of re-wriiting the exe.xml again - had no success, it never worked again.
So I'll try to send you the procmon analysis file (just running the stripped down exe.xml...) later Thanks again!
Here is the procmon log Logfile.zip
Looking through your log file in detail and comparing it to what happens for me, it's very different. On my machine, FlightSimulator starts looking at FSUIPC7.exe, then FSUIPC.exe itself fires up and starts working through its ini file. A bit later, FlightSimulator starts reading the FSUIPC lvar module.
On your machine, the first mention of FSUIPC is FlightSimulator looking at the lvar module. FSUIPC7.exe is looked at, but never gets executed. Very odd.
Ok, let's take it in another direction and try something else and reduce the number of variables we're changing.
Can you try putting this in your exe.xml
?
<?xml version="1.0" encoding="UTF-8"?>
<SimBase.Document Type="SimConnect" version="1,0">
<Descr>Autolaunch</Descr>
<Filename>exe.xml</Filename>
<Disabled>False</Disabled>
<Launch.Addon>
<Name>Notepad</Name>
<Disabled>False</Disabled>
<Path>C:\Windows\System32\notepad.exe</Path>
</Launch.Addon>
</SimBase.Document>
Just that. Super simple contents: it'll literally just run notepad when MSFS starts. This removes all the variables of how your FSUIPC7 installation is configured and all the rest of it. Your notepad.exe should be identical to mine. With the above exe.xml file, MSFS should launch an empty Notepad window some time after it starts up.
If it doesn't launch Notepad, we know it's something different between your MSFS installation compared to mine. If it does launch Notepad, it suggests there's something not quite right with your FSUIPC installation, so it would be worth testing the other startup programs one by one.
(Also, just in case there's some weird encoding issue, here is a zip containing my exact exe.xml file so you can replicate the encoding, hidden byte order markers and so on: exe.xml.zip)
Will try it in a few days...right now I'm too busy with RL tasks. btw...: I made ("just for fun") a completely fresh MSFS install on a completely new rig...and there the same happened: Exe.xml loaded once, then never again. For the moment I gave up and wrote a .bat - we'll see, I'll get back to you. Thx!
Funny things are happening...π...2 hours ago I fired up my msfs rig, a small mandatory update was applied (presumably the 'Maverick-' one...) - and since then the exe.xml loads...everytime I start the sim. Don't know why - but I'm old enough to know I won't be able to know all things...π€£...most likely les sorciers d'Asobo done their magic. Fixed. For me. For now...
Brilliant. I had noticed that a whole bunch of people suddenly started complaining all at once on flightsim.to about BBL not starting up with MSFS correctly. Does sound like Asobo messed something up but have now fixed it? Thanks for letting me know.
Thank YOU for your work and your excellent support! π
Software version
0.8.0
What are you trying to do?
Loading BBL 0.81 / exe. xml
What's the problem?
Hi,
my exe.xml doen't load after updatng it with/to work with BBL 0.81. exe.xml is - of cours EXExml.txt e renamed to EXExml.txt attached.
Would be fine if you woould find the time to look over it...
regards, Martin
What have you tried already?
Correct location of exe.xml: Checked. OK
Correct xml syntax: Checked (as far as I can tell...) OK?
Manually starting the entries in exe.xml: Checked. OK
Other information
No response