IVC closes with any keyboard press
-
Version 4.34.2 (x64) Build 20805 Detailed Description On my new system, if I open IVC and press any button on my keyboard, IVC will automatically close, without giving me any error or log-file. With IVC crashing, my computer will also noticeably lag for about 5 - 10 seconds.
The only way for me to run IVC and not have it CTD right now, is to not touch any key on my keyboard until I have successfully connected to a server through BMS (connecting in IVC itself does not prevent the CTD), AND it is not consistent. One time, IVC will stay active, but the next time, it could result in a continuous loop where the first keyboard press crashes IVC, and because I’m connected to a server with IVC enabled, it will restart IVC, only for it to automatically CTD again after 0.5 - 1s (even without any keyboard input), restart, CTD, restart, CTD, … until I close the BMS connection to the server.
I’ve tried running both BMS and IVC in normal and admin mode, compatibility modes, with and without my keyboard and mouse software, with and without other software running, even booted in safe mode, had someone send me his IVC folder… but nothing fixed it.
New computer has Win10 x64, no antivirus- or firewall-software other than what came with Windows and I have checked those are not blocking it + I have made exclusion rules for both BMS and IVC. Although it happens regardless of whether I’m connected or not, I’ve checked and verified ports are open as well.
Pictures N/A Example files N/A Crash logs None Reproducibility Procedure 1. Open BMS Launcher
2. Launch IVC
3. Press any button on my keyboard
4. IVC crashes to desktopExpected Behavior IVC not shutting down /CTD’ing with any keyboard press. I don’t do anything different than on Win7 x64, and relevant hardware (headset, keyboard, mouse) are unchanged.
-
Unable to repro – just tried this a moment ago. Given the symptoms I don’t really have any idea what the problem is and worse not even any suggestions if you don’t even get as far as generating a log file output…that’s one of the first things the app will do if you enable logging.
What’s in your client ini file?? Are you using any command line arguments/options?? Does this happen if you start the IVC binary without using the launcher to do that?? What does the OS event log say about the app crash when that happens, anything??
-
Silly I didn’t think of this myself, but I just set the IVC Client.ini-file back to default, by putting a # in front of every change I made. That fixed the issue, so going back to my edit, and disabling them one by one, it appears to be linked to the key-hook command (after disabling that command either by # or changing value to 0, IVC will not CTD)
I’m guessing that’s an issue with how Win10 handles IVC’s key-hook, as my IVC Client.ini has been working fine with that command enabled for years on Win7? It’s strange it happens with any key, instead of just F1 - F3, but I hope there’s a fix, as having this command enabled is necessary to do ATC / GCI via F4AWACS.
For full disclosure, in case it may be linked to something else in any way, this is what I have in my IVC Client.ini: (blanked out the server IP, but that is pointing to a functioning server)
# See chapter 14.5 of the BMS manual for detailed explanation of available options. # File to be saved in //localinstall/bin/x86/IVC/ #duplex = 0 server = xxx.xxx.xxx.xxx #connect = 0 nickname = EagleEye #port = #### key-hook = 1 quick = 1 #word = password #capture = sound_device #nofx = 0 #playback = Luidsprekers (Realtek High Definition Audio) #tone = #loudness = 0 #fuzz = 0 hum-level = -18 hiss-level = -18 #toneVol = 4 #uhf = 307300 #vhf = 1234 uhfVol = 6 vhfVol = 6 outsiders = all #log = 1 #minimize = 0 #force-local = 0 #noblock = 0 selfblock = 0
-
OK, great! You made good progress there. I’m not in a place to look at the code for a few days but when I am back I’ll try and see if I can mess with the key hook setting and catch it misbehaving in the debugger.
-
OK, I think I can replicate this.
An experiment if you wouldn’t mind, please.
Can you try running the 32-bit client binary instead of the 64-bit one and see if it works any better with the key hook parameter set to 1?? Let me know what happens. Thanks.
-
So I think using the 32-bit IVC Client will be the workaround for anyone wanting to use the key hook. The symptom you reported is definitely as a result of a bug. Given there is a solid workaround for it though this won’t be fixed in the code until 4.35 (fix is checked in for that already).
-
So I think using the 32-bit IVC Client will be the workaround for anyone wanting to use the key hook. The symptom you reported is definitely as a result of a bug. Given there is a solid workaround for it though this won’t be fixed in the code until 4.35 (fix is checked in for that already).
Can confirm that the issue does not exist in 32bit version of IVC Client. Thanks.
-
…as having this command enabled is necessary to do ATC / GCI via F4AWACS.
I have had exactly the same issue with “Key-hook” enabled. Thanks for the solution!
-
My friend is having the same issue with 32-bit IVC.
He said even reinstalling BMS nor uninstalling anti-virus software didn’t help.Error Log on the IVC Server:
Enter Command (h for help)> Client noname-UHF joined channel Default Channel ID=1 on virtual server 1 Client noname-VHF joined channel Default Channel ID=1 on virtual server 2 l List of clients on virtual server 1: 1 - Belmont-UHF 3 - noname-UHF Enter Command (h for help)> Client noname-GRD joined channel Default Channel ID=1 on virtual server 3 Client noname-GRD moved from channel Default Channel ID=1 to channel 243000 ID=2 on virtual server 3 l List of clients on virtual server 1: 1 - Belmont-UHF 3 - noname-UHF Enter Command (h for help)> onClientStartTalkingEvent serverID=1, clientID=noname-UHF onClientStopTalkingEvent serverID=1, clientID=noname-UHF onClientStartTalkingEvent serverID=1, clientID=noname-UHF onClientStopTalkingEvent serverID=1, clientID=noname-UHF onClientStartTalkingEvent serverID=1, clientID=noname-UHF onClientStopTalkingEvent serverID=1, clientID=noname-UHF 2020-04-16 15:50:50.037564|INFO |PktHandler |1 |Cleaning up connection because of 9 resends of COMMAND packet 2020-04-16 15:50:50.040561|INFO |PktHandler |1 |Dropping client 3 because of resend timeout Client noname-UHF left channel Default Channel ID=1 on virtual server 1 2020-04-16 15:50:53.772774|INFO |PktHandler |2 |Cleaning up connection because of 9 resends of COMMAND packet 2020-04-16 15:50:53.774773|INFO |PktHandler |2 |Dropping client 3 because of resend timeout Client noname-VHF left channel Default Channel ID=1 on virtual server 2
His IVC Client Error:
--------------------------- Error message --------------------------- Looks like there is no server running or there are connection problems, try again maybe! status: 0, error: 0x00000705, on ConID[3] --------------------------- OK ---------------------------
And its windows event log
- <event xmlns="http://schemas.microsoft.com/win/2004/08/events/event%22%3E - <System> <Provider Name=" application="" hang"=""><eventid qualifiers="0">1002</eventid> <level>2</level> <task>101</task> <keywords>0x80000000000000</keywords> <timecreated systemtime="2020-04-15T17:38:16.084181700Z"><eventrecordid>5604</eventrecordid> <channel>Application</channel> <computer>DESKTOP-81OG68V</computer> <security>- <eventdata><data>IVC Client.exe</data> <data>1.3.9.0</data> <data>2f10</data> <data>01d6134c84735a60</data> <data>11</data> <data>C:\Falcon BMS 4.34\Bin\x64\IVC\IVC Client.exe</data> <data>92b18223-05b0-4fc0-a624-fc101637b04b</data> <data><data><data>Unknown</data> <binary>55006E006B006E006F0077006E0000000000</binary></data></data></eventdata></security></timecreated></event>
-
Sorry above was 64bit IVC error.
We checked it in 32 bit again.
I saw him sharing his desktop by discord and I checked “32bit” strings bottom right corner of IVC Client.It seems windows event log does not record x86 IVC error. I don’t know why.
But its sure x86 IVC doesn’t work either. -
The logs above appear to indicate a bad internet connection. At the very least, the logs do now show anything related to the original report in this thread. Easy way to tell. Use the 32-bit or 64-bit exe and make sure that the keyhook is not set. If your friend is still having problems then it’s something else…and as I say, it looks like flaky internet connection issues.
-
Hi, I’m chihiro’s friend HULK. I’ve had a trouble with IVC. When I use IVC, It always close.
I tried BMS reinstalling and windows refoamatting. Even though this problem isn’t better.
Following passage had been displeying with IVC server PC.2020-04-30 13:38:32.263043|INFO |PktHandler |1 |Cleaning up connection because of 9 resends of COMMAND packet
2020-04-30 13:38:32.268025|INFO |PktHandler |1 |Dropping client 4 because of resend timeout
Client Viper-UHF left channel 339750 ID=2 on virtual server 1
2020-04-30 13:38:36.003548|INFO |PktHandler |2 |Cleaning up connection because of 9 resends of COMMAND packet
2020-04-30 13:38:36.010413|INFO |PktHandler |2 |Dropping client 4 because of resend timeout
Client Viper-VHF left channel 1234 ID=2 on virtual server 2 -
The logs above appear to indicate a bad internet connection. At the very least, the logs do now show anything related to the original report in this thread. Easy way to tell. Use the 32-bit or 64-bit exe and make sure that the keyhook is not set. If your friend is still having problems then it’s something else…and as I say, it looks like flaky internet connection issues.
What do you mean keyhook? I thought it means F1/F2 press in UI, but would it be an option that can disable(not set) at somewhere?
-
The keyhook command line or ini file option lets you set the IVC client up so that the push to talk keys, F1/F2/F3 are always delivered to the IVC client even if you have some other program in the foreground. My suggestion was that you have your friend, HULK I presume, try the client using the 32-bit exe and making sure that the keyhook option is not enabled. If that test fails for him also then his issue is not related to the problem reported in the original post of this thread.
That test is no longer relevant really if you have updated to apply the 4.34U4 patch because we snuck in the IVC keyhook crash fix into the U4 update.
The server log above is saying that a client is being dropped from the server because the server is unable to send information to it over the network reliably and in reasonable time. See the mentions of “resends” and “timeout”…the only known issue (of which I am aware) that would cause those messages is a bad internet/ethernet connection between the machine running the IVC client and machine running the IVC server.
Since these connections are managed for the IVC client by code that is inside the TeamSpeak3 SDK library, which we only have access to in binary form, this kind of error is not fixable by the BMS team. The only thing I can suggest is get a better internet connection I’m afraid (for example, don’t try playing Falcon4 BMS and using IVC over WiFi – get a hard line ethernet cable connection instead, etc. Actually trying multiplayer games over WiFi is generally a bad idea period if you want reliable performance of the game).
-
Mmm, well there is one other possibility…if your friend is running IVC client behind a NAT router we have seen some - ahem - creative router implementations that cause issues in port mapping. Normally for client this shouldn’t matter. To try and isolate if this might be the issue you could try putting the machine for the IVC client and the IVC server machine in a DMZ (i.e. neither machine behind any kind of NAT router) and see if that works. If it does then that would point to routing problems (…and if that’s the case you are likely on your own to fix it because that’s a local configuration issue you have to work through with the router equipment you have).
-
Dear Boxer.
I am very grateful about the matter this time.Finally, I have succed in solving the issue.
I found out that the ploblem is caused by internet connection as you said.
I canceled IPv6 and imply IPv4 option.Then I unhook NAT. -
Terrific – glad you figured it out