mirror of
https://github.com/quasar/Quasar.git
synced 2026-04-25 15:25:59 +03:00
[GH-ISSUE #1153] Unexpected disconnection makes the client undetectable from the server. #847
Labels
No labels
bug
bug
cant-reproduce
discussion
duplicate
easy
enhancement
help wanted
improvement
invalid
need more info
pull-request
question
wont-add
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/Quasar#847
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Kabir404 on GitHub (Apr 11, 2023).
Original GitHub issue: https://github.com/quasar/Quasar/issues/1153
Quasar version
1.4.1
Server installed .NET version
Whatever ships with Windows by default
Server operating system
Windows 10/Server 2019/2016
Client installed .NET version
Whatever ships with Windows by default
Client operating system
Windows 10/Server 2019/2016
Build configuration
Release
Describe the bug
After creating the client and setting its host and ports to Portmap, The client runs on the target machine and gets connected to the server pretty much instantly for the first time. But whenever the client gets disconnected unexpectedly(Like BSOD/Power Loss), The server doesnt connect to the client anymore.
At first I thought it was my own Windows install but same thing happened in my Windows 10 VM as well...
How to reproduce
Expected behavior
Even after crashes or power losses it should get detected as the client is unaffected.
Actual behavior
After crashes or power loss, It doesnt connect to the client anymore, UNLESS the client has been rebuilt and reinstalled to the target machine.
Additional context
No response
@xuebinboy commented on GitHub (Apr 26, 2023):
me too,Has the problem been solved?
@OskY-Git commented on GitHub (Apr 30, 2023):
me too
@BurntDog commented on GitHub (May 1, 2023):
I assume you enabled AutoStart and you added client file and location to the Antivirus exclusion list? If not the Antivirus (Windows Defender or third party Antivirus software) will prevent the "client" from running and delete the file.
Also make sure the client's install location can be accessed by non Admin users since you are most likely running client in non elevated user mode upon AutoStart .
@Kabir404 commented on GitHub (May 6, 2023):
The problem is with the server IMO, as if it didn't crashed it worked... By that I mean it connected normally
@MaxXor commented on GitHub (May 6, 2023):
The steps you describe to reproduce the issue and the bug description are different. Is it a crash of the client machine which causes the client to not connect anymore to the server after a reboot? Or is it a crash of the server machine with the Quasar UI to not accept any new clients after reboot? Also, the client connects to the server. Not the other way around.
@MaxXor commented on GitHub (May 6, 2023):
The only change which could hinder the client from starting up between v1.4.0 and v1.4.1 is this:
github.com/quasar/Quasar@1c7874e731It is required to enable the installation of the client for the autostart feature to work correctly. Maybe that explains it? (The autostart feature doesnt make really sense without having installation enabled)
@Kabir404 commented on GitHub (May 7, 2023):
So basically when I was interacting with the client though the server ui, power went out and after booting my PC and the server back up, it did not connect anymore....then I did some more testing and came to conclusion **that when server unexpectedly shuts down, restarting it makes the client unable to communicate with the server. But if the server was shut down gracefully(without any crashes during a connected session) then restarting the server works as it should.... **
@Kabir404 commented on GitHub (May 7, 2023):
So my bad for describing incorrectly as I didn't understand properly.
And also AV was disabled on the client as well as the host
@BurntDog commented on GitHub (May 7, 2023):
The AV would have been turned back on by default upon reboot killing the client's process then most like deleted the file. Make sure to put the client file in the AV exclusion list to avoid this.
@Kabir404 commented on GitHub (May 8, 2023):
Yes it's in the exceptions list but the thing that bugs me out is that even reinstalling the same client doesn't work it has to be a new one...
@xtremegamer1 commented on GitHub (May 25, 2023):
Do you have a lot connection addresses specified?
@BurntDog commented on GitHub (May 25, 2023):
I guess you also changed the Mutex to avoid conflicts?
@AlphaCharry commented on GitHub (Jul 18, 2023):
what f？ Can somebody tell me? Can somebody tell me what this bug is?