Date   

Re: DXLab Commander quarantined with Trojan

Phil NA4M
 

Other than an occasional scan by Malwarebytes Free I also only use W10 Security/Defender and have since system was new. 

Have run DXLab suite also since system was purchased. Never have gotten any "hits" from Defender until after today's update.  

W10 Security/Defender did spit out a message that it quarantined Commander.  I had to "Allow" it before I could get Commander to run,

Here's Defender message:

Severe

Threat blocked 03/11/2020 22:16

Status: Quarantined Quarantined files are in a restricted area where they can't harm your device. They will be removed automatically.

Threat detected: Trojan:Win32/Azden.B!c! Alert level: Severe Date: 03/11/2020 22:16 Category: Trojan Details: This program is dangerous and executes commands from an attacker.

Learn more

Affected items:

file: C:\DXLab Commander C-V Commander1440.exe


Phil NA4M


Re: DXLab Commander quarantined with Trojan

Phil NA4M
 

Yep - I ran a scan with latest Malwarebytes Free and it found nothing. 


Re: DXLab Commander quarantined with Trojan

neil_zampella
 

FWIW ... Microsoft is getting very aggressive at ham radio
programs.      The latest setup program for JTALert v2.16.0 gave a false
positive by MS Security Essentials.     One person sent in the file for
review.   An analyst reported back that while the program does not
'appear' to have any issues,  they will not be adding it to their list
of program definitions that are safe. Apparently, if the program does
not have a M$ certification, it immediately becomes suspect.      I
don't know this to be completely true, just extrapolating what I've been
seeing.

Neil, KN3iLZ


On 3/11/2020 8:57 PM, Dave AA6YQ wrote:
+ AA6YQ comments below

Suddenly today when trying to start the most recent Commander it is being quarantined by W10 Security as having a Trojan Specifically W32/Azden.Blcl

Anyone seeing same? It appears there was a W10 update including a Security update released today so perhaps related?

+ See

<https://www.dxlabsuite.com/dxlabwiki/FalsePositive>

+ Microsoft is the only "engine" reporting this.

73,

Dave, AA6YQ




--
This email has been checked for viruses by AVG.
https://www.avg.com


Re: DXLab Commander quarantined with Trojan

Dave K2XR
 

My main shack machine had the W10 upgrade finished a few hours ago.   Ran commander  no warnings and works fine.   Protection by Microsoft only.   Quarantined is a term used by Mcaffee for sure and maybe others.   I have never seen  Defender quarantine anything by that terminology.

  XR

On 3/11/2020 8:57:31 PM, Dave AA6YQ wrote:
+ AA6YQ comments below

Suddenly today when trying to start the most recent Commander it is being quarantined by W10 Security as having a Trojan Specifically W32/Azden.Blcl

Anyone seeing same? It appears there was a W10 update including a Security update released today so perhaps related?

+ See

<https://www.dxlabsuite.com/dxlabwiki/FalsePositive>

+ Microsoft is the only "engine" reporting this.

73,

Dave, AA6YQ





Re: DXLab Commander quarantined with Trojan

Dave AA6YQ
 

+ AA6YQ comments below

Suddenly today when trying to start the most recent Commander it is being quarantined by W10 Security as having a Trojan Specifically W32/Azden.Blcl

Anyone seeing same? It appears there was a W10 update including a Security update released today so perhaps related?

+ See

<https://www.dxlabsuite.com/dxlabwiki/FalsePositive>

+ Microsoft is the only "engine" reporting this.

73,

Dave, AA6YQ


DXLab Commander quarantined with Trojan

Phil NA4M
 

Suddenly today when trying to start the most recent Commander it is being quarantined by W10 Security as having a Trojan   Specifically W32/Azden.Blcl

Anyone seeing same?    It appears there was a W10 update including a Security update released today so perhaps related?

73 Phil NA4M


Re: DXV Behavior

David Bunte
 

Dave -

In safe mode the behavior was what I expected. I rebooted (out of safe mode) and tried again... now it is again behaving normally.

I do wonder if I have failed to correctly configure MS Defender to consider DXLab programs as safe. because sometimes stuff seems very slow... but I'll worry about that another day.

Thanks,

Dave - K9FN

On Wed, Mar 11, 2020 at 4:34 PM Dave AA6YQ <aa6yq@...> wrote:
This afternoon I am seeing something that I don't believe was happening in the past.

About 90 minutes ago I worked VP2VB before taking a break for lunch. When I came back to the rig the "arrow" at the left side of my log was at the VP2VB QSO and DXV showed the bands and modes on which I have worked that country. I believe that has always been the case.

I then saw a spot for 3B8XF. I double clicked on the spot and my rig QSYed to the frequency of the 3B8, the call was entered into the Capture window, my log displayed all my previous QSOs with 3B8XF, and DXV showed my band/mode progress for 3B8. Again, that is the behavior I have come to consider normal.

I could not hear the 3B8, so I cleared the capture window, my full log page was again displyer, with the "arrow" to the left of my VP2VB QSO, but DXV was still showing 3B8. I clicked on other log entries and DXV did not change. I double clicked on other log entries which then displayed previous QSOs with those calls, but DXV did not change. 

ONLY if I double clicked on a different call in SC did DXV then change to show the status of that country. If entered a call directly into the callsign window of DXV and then clicked "Go", then DXV did correctly show the status of that country... but I could only get DXV to correctly show the status of my latest (or any other) QSO if I entered that call, prefix, or country directly into the apropriate window in DXV.

Did something change, or am I totally mistaken about how DXV worked previously?

+ Clicking on one of DXKeeper's Log Page Display entries with DXView running should direct DXView to perform a "lookup" operation on the entry's callsign, as if you'd typed that callsign into DXView's Main window and struck the enter key. If that's not happening, please reboot Windows into "Safe Mode with Networking", start DXKeeper and DXView, and click on a Log Page Display Entry; how does DXView respond?

      73,

            Dave, AA6YQ





Re: DXV Behavior

Dave AA6YQ
 

This afternoon I am seeing something that I don't believe was happening in the past.

About 90 minutes ago I worked VP2VB before taking a break for lunch. When I came back to the rig the "arrow" at the left side of my log was at the VP2VB QSO and DXV showed the bands and modes on which I have worked that country. I believe that has always been the case.

I then saw a spot for 3B8XF. I double clicked on the spot and my rig QSYed to the frequency of the 3B8, the call was entered into the Capture window, my log displayed all my previous QSOs with 3B8XF, and DXV showed my band/mode progress for 3B8. Again, that is the behavior I have come to consider normal.

I could not hear the 3B8, so I cleared the capture window, my full log page was again displyer, with the "arrow" to the left of my VP2VB QSO, but DXV was still showing 3B8. I clicked on other log entries and DXV did not change. I double clicked on other log entries which then displayed previous QSOs with those calls, but DXV did not change.

ONLY if I double clicked on a different call in SC did DXV then change to show the status of that country. If entered a call directly into the callsign window of DXV and then clicked "Go", then DXV did correctly show the status of that country... but I could only get DXV to correctly show the status of my latest (or any other) QSO if I entered that call, prefix, or country directly into the apropriate window in DXV.

Did something change, or am I totally mistaken about how DXV worked previously?

+ Clicking on one of DXKeeper's Log Page Display entries with DXView running should direct DXView to perform a "lookup" operation on the entry's callsign, as if you'd typed that callsign into DXView's Main window and struck the enter key. If that's not happening, please reboot Windows into "Safe Mode with Networking", start DXKeeper and DXView, and click on a Log Page Display Entry; how does DXView respond?

73,

Dave, AA6YQ


DXV Behavior

David Bunte
 

This afternoon I am seeing something that I don't believe was happening in the past.

About 90 minutes ago I worked VP2VB before taking a break for lunch. When I came back to the rig the "arrow" at the left side of my log was at the VP2VB QSO and DXV showed the bands and modes on which I have worked that country. I believe that has always been the case.

I then saw a spot for 3B8XF. I double clicked on the spot and my rig QSYed to the frequency of the 3B8, the call was entered into the Capture window, my log displayed all my previous QSOs with 3B8XF, and DXV showed my band/mode progress for 3B8. Again, that is the behavior I have come to consider normal.

I could not hear the 3B8, so I cleared the capture window, my full log page was again displyer, with the "arrow" to the left of my VP2VB QSO, but DXV was still showing 3B8. I clicked on other log entries and DXV did not change. I double clicked on other log entries which then displayed previous QSOs with those calls, but DXV did not change.  

ONLY if I double clicked on a different call in SC did DXV then change to show the status of that country. If entered a call directly into the callsign window of DXV and then clicked "Go", then DXV did correctly show the status of that country... but I could only get DXV to correctly show the status of my latest (or any other) QSO if I entered that call, prefix, or country directly into the apropriate window in DXV.

Did something change, or am I totally mistaken about how DXV worked previously?

Tnx es 73 de Dave - K9FN


Re: DXKeeper: automatic recomputing of award progress suddenly very slow

Dave AA6YQ
 

+ AA6YQ comments below

Hi Dave, the problem has been rectified thank you. I did upgrade to 15.4.6. I disabled all award tracking, then re-enabled which rebuilt the databases, I guess.

+ Disabling Realtime Award Tracking for an award, re-enabling it, and then invoking the Recompute function does rebuild the Realtime Award Tracking database table for that award.

Also re-booted, and now it seems to be working fine again.

+ I suspect that re-booting Windows would have been sufficient.

73,

Dave, AA6YQ


Re: DXKeeper: automatic recomputing of award progress suddenly very slow

Jan AE7U
 

Hi Dave, the problem has been rectified thank you.  I did upgrade to 15.4.6.  I disabled all award tracking, then re-enabled which rebuilt the databases, I guess.  Also re-booted, and now it seems to be working fine again.

73's

Jan, AE7U


Re: LOTW and DXKeeper issue

Dave AA6YQ
 

+ AA6YQ comments below

I recently uploaded my four QSO's that I had with VP8PJ from DXKeeper to LoTW. The upload went fine and a couple of days later when I logged into my LoTW account I saw that they were showing as confirmed. When I next sync'd my QSL's in DXKeeper only three of the QSO's showed up as confirmed. The fourth QSO just shows LOTW sent -Y and LOTW Rcvd as -R. If I log into LOTW directly all four QSO's show up as confirmed. Should I just manually fix this or is there something wrong?

+Please do the following:

1. locate the entry for the fourth QSO in DXKeeper's Log Page Display

2. right-click the entry and select "Update from LoTW"

3. if this does not set the QSO's "LoTW QSL Rcvd" item to 'Y', then

3a. attach the file LoTW_UpdateSincle_ADI.txt from DXKeeper's Databases folder to an email message,

3b. send the email message to me via aa6yq (at) ambersoft.com

73,

Dave, AA6YQ


LOTW and DXKeeper issue

Jon Hall
 

I recently uploaded my four QSO's that I had with VP8PJ from DXKeeper to LoTW. The upload went fine and a couple of days later when I logged into my LoTW account I saw that they were showing as confirmed. When I next sync'd my QSL's in DXKeeper only three of the QSO's showed up as confirmed. The fourth QSO just shows LOTW sent -Y and LOTW Rcvd as -R. If I log into LOTW directly all four QSO's show up as confirmed. Should I just manually fix this or is there something wrong?

Note: When I first sync'd the QSL's I got a message that one QSO was missing the grid square and that it was built from Lat/Long. I checked and the grid square was correct. Not sure why this one QSO was different.

Jon...kf2e


Re: DXKeeper: automatic recomputing of award progress suddenly very slow

Dave AA6YQ
 

+ AA6YQ comments below

Since yesterday, my DXKeeper recompute function has suddenly slowed down dramatically. It used to work almost instantaneously - probably taking a few milliseconds. Now it takes about a minute or so. While recomputing, you cannot log (the next) QSO, so I had to disable it. It is not a matter of challenging the resources on my PC as Task Manager shows everything is normal. I am wondering if anyone has any suggestions on how to fix it?

+ Did you upgrade to DXKeeper 15.4.6 yesterday? If so, did you update your firewall and anti-malware applications to consider it "safe"?

+ Have you tried rebooting Windows?

73,

Dave, AA6YQ


Re: broke qsos

Hasan Schiers N0AN
 

Tnx Dave, there were a ton of them left over from 2001 satellite qsos.
73, N0AN
Hasan


On Wed, Mar 11, 2020 at 8:58 AM Dave AA6YQ <aa6yq@...> wrote:
+ AA6YQ comments below

I had a LOT of these when I brought old 2001 year satellite qsos in with a sloppy *.adi file.

The  grid squares looked "good", but until I went into EDIT and deleted the grid square, and then re-entered it, I would keep getting the error.

+ The QSO's latitude or longitude was invalid or inconsistent with the grid square. Re-entering the grid square corrected the latitude and longitude to match the grid square.

       73,

            Dave, AA6YQ






Re: Finally! My DXK is Clean

Hasan Schiers N0AN
 

Understand (on dupes). The error logs are so superb that it was easy to catch and fix.
73, N0AN
Hasan


On Wed, Mar 11, 2020 at 8:56 AM Dave AA6YQ <aa6yq@...> wrote:
+ AA6YQ comments below

It turns out that even one error in an upload to LoTW, prevented all the good qsos from uploading. (which is in the documentation)

When editing the log I found if I had 50 qsos with one station (not uncommon for satellite work), and only one of them had an error (like missing bands info, bad grid, etc), then none of them would "clean up" with respect to LoTW, when I tried to "Add Requested"

+ That's because TQSL rejects an entire batch of QSOs to be uploaded if any one of them is defective.


Two duplicates remained after I did a Ctrl-Sync LoTW QSOs): Both were identical in every respect, including time EXCEPT one said DATA and the other said FT4.

These were left over from when LoTW did not support FT4 and TQSL changed them to DATA or I entered them as DATA when FT4 was not yet supported.

It seems to me that a dupe check should, if it observed this case, consider it a dupe:

Those two entries have everything else exactly the same, including time, but have different modes.

I say this because it seems logically impossible to run two modes at precisely the same date/time.

+ I disagree. It is certainly possible to make two QSOs during the same minute.  It may not be possible to make two QSOs during the same second with today's modes, but this could become possible in the future.

     73,

             Dave, AA6YQ





Re: broke qsos

Dave AA6YQ
 

+ AA6YQ comments below

I had a LOT of these when I brought old 2001 year satellite qsos in with a sloppy *.adi file.

The grid squares looked "good", but until I went into EDIT and deleted the grid square, and then re-entered it, I would keep getting the error.

+ The QSO's latitude or longitude was invalid or inconsistent with the grid square. Re-entering the grid square corrected the latitude and longitude to match the grid square.

73,

Dave, AA6YQ


Re: Finally! My DXK is Clean

Dave AA6YQ
 

+ AA6YQ comments below

It turns out that even one error in an upload to LoTW, prevented all the good qsos from uploading. (which is in the documentation)

When editing the log I found if I had 50 qsos with one station (not uncommon for satellite work), and only one of them had an error (like missing bands info, bad grid, etc), then none of them would "clean up" with respect to LoTW, when I tried to "Add Requested"

+ That's because TQSL rejects an entire batch of QSOs to be uploaded if any one of them is defective.


Two duplicates remained after I did a Ctrl-Sync LoTW QSOs): Both were identical in every respect, including time EXCEPT one said DATA and the other said FT4.

These were left over from when LoTW did not support FT4 and TQSL changed them to DATA or I entered them as DATA when FT4 was not yet supported.

It seems to me that a dupe check should, if it observed this case, consider it a dupe:

Those two entries have everything else exactly the same, including time, but have different modes.

I say this because it seems logically impossible to run two modes at precisely the same date/time.

+ I disagree. It is certainly possible to make two QSOs during the same minute. It may not be possible to make two QSOs during the same second with today's modes, but this could become possible in the future.

73,

Dave, AA6YQ


DXKeeper: automatic recomputing of award progress suddenly very slow

Jan AE7U
 

Good morning,

Since yesterday, my DXKeeper recompute function has suddenly slowed down dramatically.  It used to work almost instantaneously - probably taking a few milliseconds.  Now it takes about a minute or so.  While recomputing, you cannot log (the next) QSO, so I had to disable it.  It is not a matter of challenging the resources on my PC as Task Manager shows everything is normal.  I am wondering if anyone has any suggestions on how to fix it?

73's,
Jan, AE7U


Re: broke qsos

Hasan Schiers N0AN
 

I had a LOT of these when I brought old 2001 year satellite qsos in with a sloppy *.adi file.

The  grid squares looked "good", but until I went into EDIT and deleted the grid square, and then re-entered it, I would keep getting the error.

Once re-edited and saved the grid square error went away.
73, N0AN
Hasan


On Tue, Mar 10, 2020 at 7:29 PM Dave AA6YQ <aa6yq@...> wrote:
+ AA6YQ comments below

I have some broken QSOs with LA9VFA. Error message: invalid gridsquare.
This ham operated from two different locators, but call was the same, as
an /A or is not recommended in Norway.

What is the fix for this?

+ The "fix" is to specify a valid grid square. What grid squares are logged with your LA9VFA QSOs?

       73,

              Dave, AA6YQ