EDCD / EDDI

Companion application for Elite Dangerous
Other
444 stars 81 forks source link

Application closes itself on load (if Elite Dangerous has not run previously) #253

Closed RoyKillington closed 6 years ago

RoyKillington commented 6 years ago

Steps to reproduce

  1. Attempt to start EDDI (multiple versions)
  2. Loads EDDI, can interact with for ~.5 seconds before freezing
  3. EDDI closes itself within 4 seconds

Expected

I expected EDDI to launch and stay launched? It's worked before (2.4.3 before it updated to 2.4.5 for me yesterday), I was customizing EDDI in a new personality profile, though I have yet to use in-game.

Observed

The program loads, I had just enough time to click the "Report and Error" button before I can no longer interact. The cursor changes to the loading version, a few seconds pass, EDDI closes itself.

Investigation

I've attempted multiple versions since it updated from 2.4.3 to 2.4.5. Uninstalled and reinstalled from 2.4.2 up to current beta release (2.4.6-b1), all have the same issue. 2.4.3 informs me that an update is available before crashing. No sign of the process in Task Manager after it closes. Tried to start all versions tested with Voice Attack both on and off. Tried a work-around I found after poking around (https://forums.frontier.co.uk/showthread.php?p=6135025&viewfull=1#post6135025) it didn't work either. Tried turning of Windows SmartScreen when installing 2.4.6-b1, still no different. I'm stumped as to why it keeps closing after 4 seconds.

**Upon viewing Task Manager (Windows 10 64-bit) when attempting to launch, EDDI launches and then within 2 seconds appears to launch again. Screenshot attached. capture

**Weirdly enough, I tried installing 2.3 and that works fine. No crashing. Worked through updating, and it kept working up to 2.4.4. It tried to update to 2.4.5 and crashed during the update. Tried again, now the same problem is occurring.

captroper commented 6 years ago

I have the same issue with version 2.4.5. Launching EDDI directly causes the app to hang after around half a second and then crash. Launching Voice Attack instead causes a crash as soon as the plugin is loaded. Launching voice attack with plugins disabled causes no crash. Clicking Debug after the crash says, "An unhandled exception of type 'System.NullreferenceException' occured in EddiJournalMonitor.dll"

Tkael commented 6 years ago

Sorry to hear you're having trouble. There may be a problem with your config files?

  1. In your filesystem, navigate to %APPDATA%/EDDI.
  2. Cut and paste everything from that folder to your desktop. You should now be able to start EDDI.
  3. Close EDDI, move one of the files back into %APPDATA%/EDDI, and attempt to re-open EDDI.
  4. Repeat for each file that was in your folder.
  5. When EDDI begins to crash again, you've identified the file that is causing the crash. Let us know what you find, then:
    • If the file is credentials.json or edsm.json: delete the file (these contain sensitive data so we don't recommend sharing their contents)
    • If the file is not one of those two, you can post it here prior to deleting and we can examine the file to figure out why it could cause a crash.
  6. Return the rest of the files to the %APPDATA%/EDDI directory (depending on which file you deleted, you may need to re-input some settings in EDDI).
RoyKillington commented 6 years ago

So, I went to try what you suggested in a fresh install of 2.4.5 (this install still had the crash issue and was done after specifically deleting the APPDATA folder). It immediately repopulated the APPDATA folder, but, neither the fresh install nor the repopulation contain either credentials.json or edsm.json so I'm not sure what to do from there. It does contain a text doc (eddi.log) which appears to indicate that EDDI could not find either elite.json or credentials.json so I'm thinking that may be my problem. Would you like me to upload this log file?

Tkael commented 6 years ago

If EDDI doesn't find a config file when it is loaded them it will create one. Credentials.json and edsm.json should be recreated once you log in to the Frontier API and EDSM respectively. If they are missing, it should not cause EDDI to crash. If you are still getting crashes, the config files are unlikely to be the problem. I'm starting to think that there's a problem with the install.

Tkael commented 6 years ago

Try reinstalling, using a suggestion from the forums?

I wanted to share my research and findings regarding EDDI crash on launch:

Windows 10 doesn't like unsigned programs. EDDI is unsigned. When EDDI is downloaded, the executable is "blocked" by SmartScreen. Attempting to install a blocked program will generate a prompt to the user asking "Continue anyway?" or some such.

The problem is, even if a user "Continues anyway" EDDI is not properly installed. I cannot speak to exactly what remains blocked, despite election to proceed with installation, but something is. This blocked something is the reason EDDI crashes immediately upon launch, either as standalone, or via VoiceAttack.

My solution was to "unblock" the installation executable prior to installation. Right Click -> Properties -> [x] Unblock -> [Apply]

Fly safe, CMDRs.
captroper commented 6 years ago

Apologies for my earlier post, I was apparently just being stupid. I hadn't yet started the game and apparently that made a difference. After starting the game I tried again to launch EDDI and it worked without issue.

Tkael commented 6 years ago

Hmm. As in, you'd never run Elite Dangerous on that computer before? If so then they may have made a difference. EDDI would have looked for the folder where your player journal files are stored, and may have crashed if that folder was not found.

captroper commented 6 years ago

Correct, that was my assumption as well.

Tkael commented 6 years ago

Ok. Then we can look at hardening EDDI against that kind of error. Glad you were able to sort it out. o7

richardbuckle commented 6 years ago

Re hardening I think it would be sufficient to create an empty directory at the proper location if none is found, then continue to run normally. It's not like the directory has special permissions or anything.

Tkael commented 6 years ago

Fixed on PR #283, pending approval.