Faulting application name: mRemoteNG.exe, version: 1.76.20.24669 (Windows11 Pro) about mremoteng

[DocMoebiuz]

Ok... that did the trick for me:

• Disable internet
• Start mRemotNG
• Enable Internet again

Optionally:

• Disable check for update on start

But I would assume this is a temporary issue as long as their website is down.

[mgoegel]

Same here and quickly had the same idea, that it is due to the website, which I checked first...
This might be a bug report, if the response from the update url is not as expected.

[tolew1]

Same here and quickly had the same idea, that it is due to the website, which I checked first... This might be a bug report, if the response from the update url is not as expected.

The workaround is working. No internet, then disable check for updates. It definitely should be a bug report. The app should never depend on an external site with no error handling in case it was ever offline.

[simonai1254]

The website is back online, I was able to start 1.76.20 without experiencing any issue.

I guess the problem was, that even though the queried URL got resolved it returned something unexpected, which was not handled correctly by the tool.
This needs to be investigated further and get fixed in the newer versions as it cannot be that the tools stops working just because an unexpected answer is returned by the webserver. The "Disabling the network" and "Hosts-File Redirect" workarounds indicate to me that it's not domain unreachable thing but more related to what Squarespace replied with to the query from the tool.

[simonai1254]

So I looked a little into this and I stumpled across issue #1959 which seems to support my theory of the update handler not being able to parse anything else but plain text replies from the webserver. You should check if the merge #1960 (into 1.77.3) actually solves this issue.
Also in my research I found #1533 which already documented the workaround of disabling the Update Check.
Lastly #527 (comment) gives some interesting insight in the URLs the updater tries to access, maybe this helps isolating the true issue.

@Kvarkas I guess we should proceed with making one issue (I suppose this one as it now holds most information) the main one and closing the related (/duplicate) issues in favor of having all discussions on one place. I identified following issues being based on the same problem (inlcuding the ones mentioned above):

• #527
• #1533
• #1839
• #1937
• #1959
• #1960
• #2541
• #2542
• #2543
• #2544

[wincentblack]

The same situation after update to new version:

Exception Message
"An item with the same key has already been added."

Stack trace
   at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
   at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
   at System.Collections.Generic.Dictionary`2.Add(TKey key, TValue value)
   at mRemoteNG.App.Update.UpdateFile.FromString(String content) in C:\jenkins\workspace\Publish\Build mRemoteNG for Release\mRemoteV1\App\Update\UpdateFile.cs:line 57
   at mRemoteNG.App.Update.UpdateFile..ctor(String content) in C:\jenkins\workspace\Publish\Build mRemoteNG for Release\mRemoteV1\App\Update\UpdateFile.cs:line 22
   at mRemoteNG.App.Update.UpdateInfo.FromString(String input) in C:\jenkins\workspace\Publish\Build mRemoteNG for Release\mRemoteV1\App\Update\UpdateInfo.cs:line 32
   at mRemoteNG.App.Update.AppUpdater.GetUpdateInfo() in C:\jenkins\workspace\Publish\Build mRemoteNG for Release\mRemoteV1\App\Update\AppUpdater.cs:line 247
   at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart()

Environment
OS: Microsoft Windows NT 10.0.22621.0
mRemoteNG Version: 1.77.1.27654
Edition: MSI
Cmd line args: 

[DocMoebiuz]

Same

Application: mRemoteNG.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.ArgumentException
   at System.ThrowHelper.ThrowArgumentException(System.ExceptionResource)
   at System.Collections.Generic.Dictionary`2[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089],[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].Insert(System.__Canon, System.__Canon, Boolean)
   at System.Collections.Generic.Dictionary`2[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089],[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].Add(System.__Canon, System.__Canon)
   at mRemoteNG.App.Update.UpdateFile.FromString(System.String)
   at mRemoteNG.App.Update.UpdateFile..ctor(System.String)
   at mRemoteNG.App.Update.UpdateInfo.FromString(System.String)
   at mRemoteNG.App.Update.AppUpdater.GetUpdateInfo()
   at System.Threading.ThreadHelper.ThreadStart_Context(System.Object)
   at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
   at System.Threading.ThreadHelper.ThreadStart()

[DocMoebiuz]

I think it might be because their website is down... it looks like the exception is raised when checnking for the latest version.

at mRemoteNG.App.Update.AppUpdater.GetUpdateInfo()

I will try to disable my internet connection while starting.

[zanna241]

Ok... that did the trick for me:

• Disable internet
• Start mRemotNG
• Enable Internet again

Optionally:

• Disable check for update on start

But I would assume this is a temporary issue as long as their website is down.

working for me!!

[alvinlgs]

I encountered the same issue. Here's what I did:

1. Delete the configuration file
   (%LOCALAPPDATA%\mRemoteNG<most recently updated folder><mRemoteNG version>\user.config)
2. Uninstall
3. Install the latest stable build
4. Customise Settings on the first start to disable auto update

[Rhodester]

Same problem for me on Win 10 Pro.
I preferred to keep my config file settings so I rather did the following.

1. Open / Edit %LOCALAPPDATA%\mRemoteNG<most recently updated folder><mRemoteNG version>\user.config
2. Search for "CheckForUpdatesOnStartup" and change to "False".

[wincentblack]

I think it might be because their website is down... it looks like the exception is raised when checnking for the latest version.

at mRemoteNG.App.Update.AppUpdater.GetUpdateInfo()

I will try to disable my internet connection while starting.

Thanks for tips! it did a trick, nice catch

[DocMoebiuz]

it's not limited to win 10

[DocMoebiuz]

@wincentblack wjx did you decide to close this issue in favor of the other one if this one here contains specific steps for a work around?

there should be an issue created now that says: don't fail on start up when check for update URL not available / returning correct response

[Kvarkas]

Sorry for that! Domain relocation in progress, but that for sure a bug, will make a change so in feature if domain not availbale it will not generate an error.

[simonai1254]

Sorry for that! Domain relocation in progress, but that for sure a bug, will make a change so in feature if domain not availbale it will not generate an error.

Note sure if it's a resolving issue or that the page is not responding with a 200 message, because the website (to me) was displaying a dummy Squarespace page while reports were coming in...

[Kvarkas]

yes, its 3 steps process, relocation to new hoster, then all that started, then new hoster acepted, second step was to set dns records to github that they say takes up to 24h, what you see now is new hoster temporary page, once Github finished its verefication (what ever they do) it should start pointing to github pages where all data is stored and work will be normilised :) its tought change so was selected festive time to have less impact on users. But wasnt expected it impact that way!

[Kvarkas]

it could be not finished for all regions, but I am sure it will till morning :) complete usualy in 24h, 15 already pass :)
In fact its coded a bit rude way its explicitly requested data and have no any handler if data will not received - so its crashed. Will definitely work on such, should be easy fix.

[Kvarkas]

will be celebrating new year tomorrow so back to work on this from 2nd of January. Yes good idea to aggregate into one and close others. Thanks for such.