Applications that can Interfere with DXLab Applications
Firewall, antivirus, and other anti-malware applications can cause DXLab applications to start or perform slowly, prevent them from interoperating, or prevent them from accessing the internet. To avoid this, consider configuring your anti-malware applications to consider each of your DXLab applications to be safe.
- These applications have been reported to slow the startup or execution of DXLab applications, or to cause TCP ports to be reported as "already in use":
Adobe Creative Cloud Suite can slow the startup of DXLab applications
Akamai NetSession Client significantly slows the startup of DXLab applications; the only known cure is to prevent Akamai NetSession Client from running.
BitDefender includes problematic components:
Advanced Threat Defense causes the delays in logging, delays in callsign lookups, and slows both application startup and shutdown
Ransomware Remediation prevents SpotCollector from connecting to DX Summit via IRC, even with an exception specified
BullGuard Firewall can cause DXLab applications to report that TCP ports are already in use
Dashlane, a free password manager, can cause DXLab applications to start slowly
DropBox can cause DXLab applications to run slowly
Elgato's Stream Deck utility can cause DXLab applications to start and run slowly
Flow, an application included in HP computers with a Conexant audio chipset, can autonomously but silently mute soundcard microphone inputs by enabling its mute all microphones option.
Kaspersky Antivirus can disconnect SpotCollector's spot sources, changing their status indicators from green to yellow
MalwareBytes, when configured for continuous monitoring, has been reported to cause significant slowdowns, however, one-time scans are not problematic; see the Additional Notes below.
Nero Video Downloader and Video Downloader Ultimate can cause DXLab applications to run slowly
Norton Security has been reported to cause significant slowdowns
nVidia's GEFORCE EXPERIENCE application with its IN-GAME OVERLAY option enabled causes DXLab applications to start very slowly
PiP Anywhere by TODO can cause DXLab applications to start slowly
SetPoint and LCore by Logitech can cause DXLab applications to run slowly
WaveNode RF meter software can prevent DXKeeper from interoperating with LoTW
Windows Defender by Microsoft can erroneously declare a DXLab application to contain malware, and quarantine it; in response, you can
have other anti-virus applications check the DXLab application for the presence of malware
configure Windows Defender to consider a DXLab application to be safe by by defining an exclusion
recreate a DXLab executable that Windows Defender erroneously quarantined or deleted
TightVNC and AnyDesk fabricate MouseUp events. When Commander receives a MouseUp event for the F1 function key, it interprets this to mean "restore the original VFO selected at the beginning of a swap VFOs function", and sends the appropriate command to the transceiver.
- The application RCV7, transceiver control software for Kenwood's TM-V7 FM Dual Band Transceiver, can interfere with the DXLab Launcher
When some applications are installed -- notably anti-malware applications -- they configure Windows to automatically start them when Windows starts. To determine whether an application being automatically started by Windows is interfering with your DXLab applications, boot windows into Safe Mode with Networking as described below. If booting Windows into Safe Mode with Networking and then starting the affected DXLab applications eliminates the slow startup and slow performance, enables interoperation, or restores access to the internet, that's a strong indication of interference by one of the applications that Windows is configured to automatically start when booted normally. Note that when Windows is booted into Safe Mode with Networking, device drivers are not loaded, so Commander won't be able to communicate with your transceiver(s) and DXView won't be able to communicate with your antenna rotator.
Booting Windows into Safe Mode with Networking
A DXLab application that starts up promptly in Safe Mode with Networking but takes much longer to start up when Windows has been booted normally indicates that one of the applications or services by automatically started by Windows is responsible for the behavior.
To boot Windows 2000, NT, Vista, XP, 7, or 8 into Safe Mode with Networking, follow these instructions
To boot Windows 10 into Safe Mode with Networking, follow these instructions
Determining Which Applications are being Started Automatically by Windows
To determine what applications Windows is configured to automatically start when Windows is booted normally,
on Windows 10, start the Windows Task Manager and select its Startup tab
on previous versions of Windows, start MSConfig; in the System Configuration Utility window that appears, select the Startup tab
To determine the functionality and provenance of an application that Windows is configured to automatically start, see this searchable database .
Finding the Culprit
To identify which of several possible applications is interfering,
- disable the automatic startup of all applications, and reboot Windows; confirm that no interference is present
- enable the automatic startup of one of the previously automatically-started applications, and reboot Windows
- if no interference is present, repeat step 2
- if interference is present, the last enabled application is the culprit
You can use the Startup tab in Microsoft's MSConfig tool to enable and disable startup applications.
Configuring an Anti-malware Application to Consider Each of your DXLab Applications to be Safe
- read the documentation for the anti-malware application
- if the documentation doesn't provide a sufficient explanation, contact the help desk of the anti-malware application's provider
- if you are unable to obtain timely assistance from the help desk, consider switching to a more competent anti-malware application provider
Malwarebytes de Bill G4WJS
The Malwarebytes premium version protects Internet service ports by monitoring traffic, if it sees traffic going to a local server that it does not know about it grabs that port and sits on it so no other applications can run a service on that port. It can be very confusing as the first packet of information will be delivered then the service trying to use the port then gets blocked by the Malwarebytes service that hijacks the port. This can be hard to trace using normal system tools as the hijacked port is held by a Windows service process that cannot be easily attributed to Malwarebytes.
To diagnose this, use the 'netstat -abn' command from an Administrator command prompt and check the output for the port the non-working service application is expected to be listening on. If the listening process is shown as svchost.exe then a Windows service is using the port. The final step is to move the non-working service to another free port and if that too then appears to be in use by a svchost.exe process then Malwarebytes is probably the culprit.