RCON web socket errors in console

Since the update, one of my consoles crash regularly on any of my moded servers (for my vanilla server I'm not sure, I need to see to confirm).
And once it has crashed, it is impossible to join the server with RustAdmin without restarting the server.
I use 3 Rustadmin consoles in 3 differents directory but it was not a problem before.

Any ideas ?

 

Thx for the answer I have open a Thread on Help Me - Forum

 

@Wulf
I have not received any response on the forum Rust Facepunch and zero reads :'( You could go back to them the problem of your side ? I do not necessarily have the error messages in console but there is a problem which makes crash the Rcon on the server side... I have not used Rustadmin since the restart of this morning (5 am).. And now (16 pm), I run Rustadmin and impossible to connect without restarting the serv :/

 

those errors look like the same i get.
since around almost a month now. Before it was fine, never showed that.
But since it throws those exceptions i had to turn off websocket and use for now, which works.

If i turn on websocket it freezes the server for a couple of seconds on each message , making it not possible to play as you get kicked from packet flood.
This Update i made a clean wipe- which not resolved the problem.

-- I even changed my Rcon port, and PW which also didnt help

 

I found a probable source of the bug.

I deactivated "CCUpdateCheck.cs" and "UpdateChecker.cs", I saw that "UpdateCheck.cs" gave a lot of errors for its requests at the time of the restart.
This crash also blocked the plugin "SteamGroups.cs" and "EasyVote.cs".

Since then, no Rcon crash.

Noted, that they are still active on my Vanilla under Oxide but there are fewer plugins ..

I think that "UpdateCheck.cs" badly digest one of my 99 plugins.

 

I can not say what is really the problem but it is an observation that I made.
I can recognize that I do not know entirely how the server and oxide work in the background :/

I deactivated the two plugins who check the updates on a first server... Conclusive result while my second server still posed problem.
And I did the same 24 hours later with the second server, and no more problems for several days now...
Except that I have no more information about the updates of plugins that I could miss.

 

I've seen this before.. The exception is thrown when a Websocket client is closing the connection without leaving a "closing frame" and waiting for the "
GOING_AWAY" response from your server (defined in the WebSocket W3 standard). It should not be a breaking problem - at least it wasn't for me.