"Close Launcher" setting is always enabled & crashes without elevation

[AngelusMortiel]

Starting about two days ago, I started receiving a .Net Framework error, which crashes the Discord RP client. Seemed like it coincided with a Discord update?

I've anonymised the logs below, but otherwise are untouched.

See the end of this message for details on invoking 
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.ComponentModel.Win32Exception (0x80004005): Access is denied
   at System.Diagnostics.Process.Kill()
   at ESO_Discord_RichPresence_Client.Main.UpdateClientStatus(Object sender, EventArgs e)
   at System.Windows.Forms.Timer.OnTick(EventArgs e)
   at System.Windows.Forms.Timer.TimerNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

************** Loaded Assemblies **************
mscorlib
    Assembly Version: 4.0.0.0
    Win32 Version: 4.8.4300.0 built by: NET48REL1LAST_C
    CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll
----------------------------------------
ESO_Discord_RichPresence_Client
    Assembly Version: 1.0.0.0
    Win32 Version: 1.0.0.0
    CodeBase: file:///C:/Users/User.Name/Documents/Elder%20Scrolls%20Online/live/AddOns/DiscordRichPresence/Client/DiscordStatusClient.exe
----------------------------------------
System.Windows.Forms
    Assembly Version: 4.0.0.0
    Win32 Version: 4.8.4270.0 built by: NET48REL1LAST_C
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
    Assembly Version: 4.0.0.0
    Win32 Version: 4.8.4300.0 built by: NET48REL1LAST_C
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
    Assembly Version: 4.0.0.0
    Win32 Version: 4.8.4084.0 built by: NET48REL1
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Configuration
    Assembly Version: 4.0.0.0
    Win32 Version: 4.8.4190.0 built by: NET48REL1LAST_B
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.Core
    Assembly Version: 4.0.0.0
    Win32 Version: 4.8.4320.0 built by: NET48REL1LAST_C
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll
----------------------------------------
System.Xml
    Assembly Version: 4.0.0.0
    Win32 Version: 4.8.4084.0 built by: NET48REL1
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
NLua
    Assembly Version: 1.3.2.0
    Win32 Version: 1.3.2
    CodeBase: file:///C:/Users/User.Name/Documents/Elder%20Scrolls%20Online/live/AddOns/DiscordRichPresence/Client/NLua.DLL
----------------------------------------
KeraLua
    Assembly Version: 1.3.2.0
    Win32 Version: 1.3.2.0
    CodeBase: file:///C:/Users/User.Name/Documents/Elder%20Scrolls%20Online/live/AddOns/DiscordRichPresence/Client/KeraLua.DLL
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
    <system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

[whisperity]

I cannot believe how utterly useless the error message generated is. (Not your doing, I know!) The function mentioned in the stack trace is this one:

https://github.com/Medallyon/eso-discord-rich-presence-client/blob/b83a3ae2277cce46748895790467a153ad22cd0b/ESO_Discord_RichPresence_Client/Forms/Main.cs#L195-L247

So maybe we should start from the beginning: do you have the SavedVariables file there, where it should be? (~/Documents/Elder Scrolls Online/live/ and I think SavedVariables/ESORichPresenceBlablabla under that?) Also, did you start Discord before starting the game up?

[AngelusMortiel]

Although I'm not a developer, I am extremely familiar with Powershell, so I can make a bit of sense of what is going on there. I saw the function it referenced and thought it might be the "close launcher" option of the plugin (possibly some new MDE security feature), but disabling that option didn't change anything.

Yes, I have a "DiscordRichPresence.lua" in my saved vars folder.

Finally, my Discord is running 24/7, so yes, it's running before starting the game. Specifically, my order of launching things is:

1. Discord is already running.
2. Launch Discord RP client.
3. Launch ESO.

[medallyon]

Seemed like it coincided with a Discord update?

I don't think it's caused by a Discord update since I use both every day and nothing comes up.

System.ComponentModel.Win32Exception (0x80004005): Access is denied ... it might be the "close launcher" option of the plugin

You're right. The newest update introduced a setting to the Client to automatically close the ESO Launcher (Bethesda.net_Launcher.exe) when it detects that your game (eso64.exe) has started. I noticed that it doesn't realise when that setting is toggled and attempts to close the launcher either way, which will definitely be fixed in an upcoming release.

For now, you can keep using the Client release 0.3.9. I'll update once this is fixed.

[medallyon]

Alternatively, you should be able to get around the issue by running the Client as an Administrator.

[AngelusMortiel]

Confusingly, the issue stopped yesterday. I tried to recreate it in various forms (such as RunAs admin). I'm going to assume it might have been my overzealous security software denying the client access until it had a chance to review what was being done and, now that it's checked it out, has let it proceed unhindered.

However, I'm glad it helped you find a bug, @Medallyon. Cheers!