View Issue Details

IDProjectCategoryView StatusLast Update
0002845Ham Radio DeluxeBugpublic2018-11-11 00:34
ReporterKB3NPH 
Assigned ToWA9PIE 
PriorityurgentSeveritymajorReproducibilityrandom
Status closedResolutionfixed 
Product Version 
Target VersionFixed in Version6.4.0.902 
Summary0002845: V6.4.0.876 - Random crashes\Lockups\closing of LB and DM where both are affected at the same time.
DescriptionSince the release of V6.4.0.876 support has received numerous support tickets that claim what appears to be something related to both LB and DM at the same time. Many have reported that while working in DM-780 they would develop a lock-up condition in DM and when they would check the Logbook has either just closed without any errors or has shut down displaying the standard Windows error screen indicating "This application has stopped working", with no further details. Once the Logbook has been completely closed and restarted, DM will once again be functional.

Some have reported that when the problem happens, both Logbook and DM must be restarted before they can once again gain control over those two programs. It appears that RC is never affected in any way when this happens.
Steps To ReproduceSo far, the steps to reproduce the problem is as follows:

1. Have RC, LB and DM all running.
2. Reports have been if they are working in DM-780, either in a QSO or just clicking around on the waterfall monitoring various conversations, DM will suddenly become NON-RESPONSIVE and they are unable to do anything in the program.
3. When DM becomes non-responsive, some have check the logbook and find it has either just shut down with no indication of problems. Others have reported the logbook displays the Windows error "This application has stopped working and must be closed" so they use the task manager to close Logbook.
4. Once the logbook has been closed most try to reopen it. When they reopen the logbook, they report that DM then becomes responsive again and they are able to continue normal operation until the same thing happens again.

These are just the basic steps that our customers have reported to reproduce the problem they are experiencing.


Additional InformationIn some cases mini-dumps are being created, in others no dumps are being created. The support team is now in the process of collecting mini-dumps, logfiles and other data from the customers to place in a folder in the "DUMPS" folder. The created folder will be named with this Mantis ID so that all data collected can be placed in that one folder since this issue appears to affect BOTH the LB and DM at the very same time.
TagsNo tags attached.
ModuleAll
Sub-ModuleGeneral
Testing Beta Successful

Relationships

related to 0002891 closedK7ZCZ DM780: crash at shutdown due to poor concurrency control around CLogfile object 
related to 0002900 closedK7ZCZ Digital Master: May crash while trying to post message from HRD Interface 
related to 0002901 closedK7ZCZ Digital Master: crash when freeing HRDLOG_DATA structure 
related to 0002899 closedK7ZCZ Logbook: divide-by-zero encountered in callsign lookup when machine has no hardware perf counters 

Activities

KB3NPH

2018-08-22 09:25

administrator   ~0005989

This may or may not be related, but something that might be checked. This could, however be related to Mantis ID 0456 and 1907

OSTicket#676642 customer reports that he has a different default logbook being used in the Logbook module, however, in DM > Program Options > Logbook page, the default logbook indicates "HRD My Logbook" as the logbook being used by DM. DM use to automatically indicate the database being used in the Logbook software as the database to be used in DM, however, according to this support request, is not the case. Example, if I setup a database called "KB3NPH Logbook" and select that in the Logbook software as being the DB I am using, DM indicates "HRD My Logbook" as the database to use, which is incorrect. It should automatically be showing "KB3NPH Logbook"

This can be tested by creating a totally new logbook database in the Logbook module and select that database for use for logging. Open DM-780 and click on "Program Options > Logbook" and on the bottom center of the page, it should show active logbook selected in the Logbook module. DM DOES however, have a dropdown so that you can manually select the proper database, but the majority of the users either don't know about it or forget to check it since it use to be an automatic change when the DB was changed in the LB module.

KB3NPH

2018-08-23 09:16

administrator   ~0005995

In reference to my last note further testing has provided this information. In the Logbook module, it is IMPOSSIBlE to open more than ONE logbook tab to display at any one time. At least this is what I have discovered on my own system. If you have one logbook open in a tab in the Logbook display and you select a different Logbook to be opened from the Database Pane, the first tab is closed and a it is replaced by the tab indicating the name of the logbook you selected from the Database pane. This seems to be the way the Logbook SHOULD function in all cases.

We have known for years, that in DM-780, Program Options > Logbook > you can...(if you have multiple Logbook databases configured in Logbook)... select which database to use when using DM-780. This is where a lot of support tickets are generated especially from new users of Ham Radio Deluxe who do not know this function of being able to select the DB used in DM. Confusion and support tickets are created by folks who don't realize this.

HRD Software LLC has been promoting the use of WSis for years. In the Logbook module, WSIs are used in the DX Cluster and in the ALE screens based on the Logbook Database that is currently in focus. and according to all documentation only ONE database in the Database Manager should indicate by setting the check mark in that database configuration that says "Check for "Include in 'worked status' lookup", which is then indicated in the Database Manager under the column "WSI". Only ONE database in the Database Manager should have a "Yes" in the WSI column.

Confusion comes in here. A customer can select EVERY SINGLE database, one by one, from the Logbook dropdown in DM-780. Each time a database in here is selected, it opens a logbook in a NEW TAB in the Logbook module, thus creating multiple tabs as indicated by the image I have added to this ticket. Now, as an example, if the customer selects a database that does NOT have the check "include in 'worked status' lookup, what happens is when the customer hovers over a callsign in the DM RX pane, a popup comes up indicating that the particular callsign HAS NOT been worked. It also indicates this in a little sentence added to the bottom of the ALE in DM "Not Worked" when the call is added to the ALE window in DM.

At this point, what happens is the customer then reverts back to the Logbook page, quickly opens one of the other logbook tabs, not the one that is being used by DM, and locates the call that is indicated as "Not Worked" in DM because that call has, in reality NOT been worked and added to the selected Logbook, so, since the customer DOES find that call in another log which is open in another tab in Logbook, then customer then feels the Lookup in DM is not functioning correctly and opens a support request. When this happens, we all go crazy trying to find a 'bug' in the software that does not exist because the DM lookup is functioning exactly as it's programmed to do.

Since in the Logbook module, it's impossible to open more than ONE database tab, this constraint should be extended over into the DM program also. At one point in time, as I recall, DM WAS doing this automatically. If a particular database was open in the ONE tab in the Logbook module, that same database was automatically selected in the "Program Options > Logbook >" dropdown in DM, thus eliminating any confusion about the WSI since the contact in question WAS NEVER worked and added to this database.

As has always been a problem with Ham Radio Deluxe, we need consistency in the way a certain thing works from one module to another in the suite. This could eliminate a lot of various bugs reported from customers and eliminate a lot of unnecessary work on the part of the developers in tracking down bugs that actually do not exist.

KC7FPF

2018-08-23 09:25

viewer   ~0005996

I have recently stated to look for this as well when a customer is experiencing a similar issue. I concur as the what tim as indicated here. Suggest moving forward to look at making a change here when possible.

K7ZCZ

2018-08-23 20:08

manager   ~0006001

The Logbook supports having multiple database tabs open. I do it all the time, and your screen shot shows that, too. That leaves me pretty confused about the premise of your proposal.

If everyone agrees that the Logbook should be changed so that it's possible to open only one database, we can modify it to do so. It's not too hard to implement, but I think it will be a big change for some users who have probably grown accustomed to the way it works.

I agree that it can be confusing that some databases are used in WSI lookups and some arent. 2782 and 2843 describe a couple of the issues I've found. I recently fixed 2819, which had the logbook using database that weren't configured to be involved in WSI searches.

Finally, I don't understand why this conversation is here. This issue is meant to specifically track the stability issues in the logbook, not be a catch-all discussion about how the logbook works. The implication is that the issues you're discussing are causing the Logbook stability issues reported in this issue. Is that true? If so, I don't see the connection. If not, I don't think this is the right issue. Maybe a new issue that tracks the design suggestions you've made, or another higher-level conversation about it, would be more appropriate.

WA9PIE

2018-08-25 12:17

administrator   ~0006005

Clearly, it's possible to have multiple Logbook tabs open at the same time. Frankly, I don't think there's any limit to how many you can have (nor the level of complexity created by doing so).

Yes, the purpose of this bug record is to discuss issues with Logbook closing/crashing. If there's some possibility that DM-780 is looking for a non-existent or an unopened database and this causes Logbook to close/crash, then that's an interesting part of the dialog. But the whole topic about the number of open logbook tabs was (a) false and (b) non-productive. I'd like to propose that we remove all such references about that from these comments and leave the relevant pieces in.

I'll give a day or two to look for comment on that before whacking the unrelated comments.

KB3NPH

2018-08-27 10:48

administrator   ~0006012

Today is the first I've read Mike C's comment above. I will be back in later to edit this note and explain why this should be left as it is. At the moment, I have a remote oming up that I need to handle.and don't have time to expand on this.

PD9FER

2018-09-07 08:20

viewer   ~0006105

This is a high priority one...

We are getting overloaded with this issue
Also is it widely talked about on Facebook and such.

The issue happens also an a Fresh OS install and default database setup
 Ticket# 746825

PD9FER

2018-09-07 09:30

viewer   ~0006108

Added Minidumt to the Dumps folder

K7ZCZ

2018-09-11 16:09

manager   ~0006200

The provided minidump is named "Ticket Ticket #746825 - DigitalMaster_20180906_194745.mdmp" is from build 878 of the product.

The dump shows that the application has shut down, but another thread is trying to create a log file entry. I've created Mantis 2891 to track it. I have moved the minidump to a folder for that issue on Google Drive.

The ticket isn't in a language that I speak, so I can't get any information about the context of the problem other than what's in the dump file. If repro or context information is avaialble, please add it to 2891.

PD9FER

2018-09-12 03:01

viewer   ~0006202

As a lot of customers have this...
Even now with 886 Total clean install when running RC, LB and DM... Logbook shuts down when using Digital Master.
NO minidumps nor warning popups are created.
I guess this minidump he sent is from another event.

K7ZCZ

2018-09-13 17:47

manager   ~0006206

I'm confused: you provided a minidump, but you say that no minidumps or warnings are created. Why did you think that the minidump provided was for this issue if you know that dumps aren't created?

I'd like you to please work with customers who are experiencing this issue to configure their systems to have Windows create a minidump; instructions for doing so are in this Microsoft documentation:
https://docs.microsoft.com/en-us/windows/desktop/wer/collecting-user-mode-dumps

My belief is that, once Windows is configured to keep minidumps for the crashes we don't collect ourselves, we'll be able to get dumps from customers experiencing these issues that enable investigation. Without any description of the problem, "there's a crash" is all I have to go on -- and that's simply not enough to make directed progress.

PD9FER

2018-09-14 04:00

viewer   ~0006207

The problem is, the customer found the file and added it to the ticket.
For the majority of reports, NO Minidumps or error Popups are created.

Also a new report Ticket #126100

I will continue with the customer to enable WER and see if we can get some valid data

K7ZCZ

2018-09-14 08:10

manager   ~0006208

I don't see any minidump in ticket 126100; there are no minidumps relating to Mantis 2845 in Google drive.

In Ticket 126100, the customer is told that they will see a message, then the dump will be written to C:\ProgramData\HRDLLC\. But this isn't always the case.

When Windows detects a fault in our software, it will invoke our fault handler. That handler writes a minidump to C:\ProgramData\HRDLLC\, then shows a message box to the customer identifying the file, explaining the fault, and shuts down the program.

But what you're saying is that, in the problem cases the message box never appears. That must mean that the fault is of a type for which Windows does not invoke the program's own fault handler. Certain types of program faults are assumed to be security risks, and Windows will very aggressively shut down the application -- the application's own fault handler isn't offered a chance to react to the problem. I believe that's why we're not showing our own message box and recording dump files in the usual way.

In those emergency shut-down cases, Windows still writes a minidump. The dump is sent to Microsoft (if the customer has enabled "customer experience" feedback from their system), and then deleted. Microsoft provides documentation (at this link https://docs.microsoft.com/en-us/windows/desktop/wer/collecting-user-mode-dumps) which can let a user configure the dump to go to a different directory, and to be kept after it is recorded.

Instead of telling customers to look only at the C:\ProgramData\HRDLLC\ directory and closing the ticket, I'd like to ask you (and the rest of the support staff) to please work with customers who are experiencing this issue to aggressively try to collect a dump. It's really important that we get a minidumps around the crashes in the product. Without any diagnostic information, the crashes are impossible to identify and very, very difficult to fix.

Thanks!

PD9FER

2018-09-14 09:11

viewer   ~0006209

I work with one customer which is in the Netherlands.
Only can do one at the time.

KB3NPH

2018-09-17 12:39

administrator   ~0006212

Ticket #508543 Another ticket where customer complains of DM going non-responsive and Logbook crashing without a dump. This customer provided a zip file with mini-dumps in it. Placed it in the 0002845 folder in the DUMPS file. Filename is "OSTicket #508543 DigitalMaster_20180917_161340.zip"

I believe it contains several dumps pertaining to this issue.

PD9FER

2018-09-18 03:37

viewer   ~0006213

Another report from Ticket# 912264

PD9FER

2018-09-18 07:47

viewer   ~0006214

And another one.
Ticket #221065

K7ZCZ

2018-09-18 09:24

manager   ~0006219

The "OSTicket #508543 DigitalMaster_20180917_161340.zip" file contains five minidumps. One is from the Logbook at Build 876. The others are from Build 886; three from DigitalMaster, one from HRDLogbook.

The first one I've analyzed shows a divide-by-zero error in the Logbook. I've opened Mantis 2899 to track that issue.

Of the dumps from build 886:

The logbook dump isn't useful. It shows that the process was unable to start up:

0:000> .ecxr
Unable to get exception context, HRESULT 0x8000FFFF
0:000> kb
 # ChildEBP RetAddr  Args to Child              
00 00000000 00000000 00000000 00000000 00000000 HRDLogbook!wWinMainCRTStartup [f:\dd\vctools\crt\crtw32\startup\crt0.c @ 155] 
0:000> vertarget
Windows XP Version 2600 UP Free x86 compatible
Machine Name:
System Uptime: not available
Process Uptime: not available


so I've got nothing at all to go on.


DigitalMaster_20180914_154750.mdmp shows the same logfile crash as Mantis 2891.

DigitalMaster_20180916_180608.mdmp shows an interesting crash; a message posted to the main window of the application through the HRDInterface window trips over what is apparently a bad window pointer. I've opend Mantis 2900 to track this issue and more details are in that log.

DigitalMaster_20180917_161340.mdmp is also an interesting dump. Here, we crash when trying to crash when cleaning up a data structure used to pass work (and results) to a background thread. I've opened Mantis 2901 to track this issue. This crash is similar to, but not precisely the same as, Mantis 2704.

Thanks for the reports; please keep them coming.

PD9FER

2018-09-21 12:36

viewer   ~0006228

I enabled WER at the customer via a Remote...
LB closed without notification, but WER generated HRDLogbook.exe.8620.dmp
It is in this mantis id folder in Dumps

Hope this will shed some light on the issue.

K7ZCZ

2018-09-23 18:20

manager   ~0006230

Thanks for collecting the dump file. The only way to make progress on this issue in the absence of a clear reproducable case is to collect dumps from customers.

The 8620.dmp file comes from build 886 of the product. I've got no infomration about the context of the crash, other than the Logbook program has crashed and there's a dump file.

This crash dump is useful in that we know it matches the stacks we've seen when we do get a dump from the HRD dumper; this dump file does contain an exception code that indicates the C Runtimes immediately shut down the app:

This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(21ac.2a54): Unknown exception - code c0000374 (first/second chance not available)


so I think we do learn that at least some of the sudden abends users have reported are along the code path that we've previously investigated.

Here's the exception, including the call stack with parameters:

0:018> .ecxr
eax=15ebd1d4 ebx=77a858c0 ecx=00000001 edx=77a85890 esi=00000002 edi=023d0000
eip=77a48869 esp=15ebd1b0 ebp=15ebd244 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
ntdll!RtlReportCriticalFailure+0x88:
77a48869 eb36            jmp     ntdll!RtlReportCriticalFailure+0xc0 (77a488a1)
0:018> kp
  *** Stack trace for last set context - .thread/.cxr resets it
 # ChildEBP RetAddr  
00 15ebd244 77a51a90 ntdll!RtlReportCriticalFailure+0x88
01 15ebd250 77a4f99f ntdll!RtlpReportHeapFailure+0x2f
02 15ebd284 77a5a23e ntdll!RtlpHpHeapHandleError+0x6e
03 15ebd298 779fecac ntdll!RtlpLogHeapFailure+0x41
04 15ebd2f4 00e2f987 ntdll!RtlFreeHeap+0x4cbbc
05 15ebd308 011c116d HRDLogbook!free(void * pBlock = 0x1933f6f4)+0x1a [f:\dd\vctools\crt\crtw32\heap\free.c @ 51] 
06 15ebf908 011c911c HRDLogbook!CBackgroundProcessingThreadLookups::CountryLookup(struct REQUEST_SIGNAL_DATA * pSignalData = 0x1933f6f4, struct _tagCallsignLookup * pData = 0x1933f574, int nThreadNumber = 0n-1)+0x886d [c:\ham radio\logbook\hrdlogbook\backgroundprocessingthreadlookups.cpp @ 4927] 
07 15ebf93c 011b1adf HRDLogbook!CBackgroundProcessingThreadLookups::ProcessData(class CBkgPacket * pPkt = 0x08e2ec58, int nCount = 0n0)+0xbc [c:\ham radio\logbook\hrdlogbook\backgroundprocessingthreadlookups.cpp @ 178] 
08 15ebf974 0138fbd0 HRDLogbook!CBackgroundProcessingThread::DoWork(void)+0xaf [c:\ham radio\logbook\hrdlogbook\backgroundprocessingthread.cpp @ 307] 
09 15ebf99c 0138fb16 HRDLogbook!CThinThread::Run(void)+0x80 [c:\ham radio\logbook\hrdlogbook\thinthread.cpp @ 188] 
0a 15ebf9d8 00e32e4b HRDLogbook!CThinThread::Start(void * pv = 0x0167a9d8)+0x46 [c:\ham radio\logbook\hrdlogbook\thinthread.cpp @ 236] 
0b 15ebfa10 00e32f73 HRDLogbook!_callthreadstartex(void)+0x1b [f:\dd\vctools\crt\crtw32\startup\threadex.c @ 376] 
0c 15ebfa1c 74268484 HRDLogbook!_threadstartex(void * ptd = <Value unavailable error>)+0x7c [f:\dd\vctools\crt\crtw32\startup\threadex.c @ 354] 
0d 15ebfa30 779d305a kernel32!BaseThreadInitThunk+0x24
0e 15ebfa78 779d302a ntdll!__RtlUserThreadStart+0x2f
0f 15ebfa88 00000000 ntdll!_RtlUserThreadStart+0x1b


We note that the block being freed is at 0x1933f6f4, which tunrs out to be within the stack of one of the running threads:

  26  Id: 21ac.257c Suspend: 1 Teb: 00be8000 Unfrozen
 # ChildEBP RetAddr  Args to Child              
00 1933f5ac 7348afd9 00000c24 00000001 00000000 ntdll!NtWaitForSingleObject+0xc
01 1933f618 7349f4e5 00000001 00000004 1749900c mswsock!SockWaitForSingleObject+0x139
02 1933f724 77825e9e 00000040 1933f860 00000000 mswsock!WSPSelect+0x485
03 1933f7c0 012800ca 00000040 1933f860 00000000 ws2_32!select+0xbe
04 1933f98c 01283030 7a471403 00e33516 00e33516 HRDLogbook!CIpThread::ProcessConnection+0xaa [c:\ham radio\logbook\hrdlogbook\iplistener.cpp @ 1701] 
05 1933f9c8 00e334c5 147eaa40 7a4717cb 00e33516 HRDLogbook!CIpThread::StartThreadPoint+0xb0 [c:\ham radio\logbook\hrdlogbook\iplistener.cpp @ 725] 
06 1933fa00 00e3356c 1933fa1c 74268484 146ae058 HRDLogbook!_callthreadstart+0x1b [f:\dd\vctools\crt\crtw32\startup\thread.c @ 255] 
07 1933fa08 74268484 146ae058 74268460 0f1537fa HRDLogbook!_threadstart+0x56 [f:\dd\vctools\crt\crtw32\startup\thread.c @ 237] 
08 1933fa1c 779d305a 146ae058 0c8e97d9 00000000 kernel32!BaseThreadInitThunk+0x24
09 1933fa64 779d302a ffffffff 779eeca1 00000000 ntdll!__RtlUserThreadStart+0x2f
0a 1933fa74 00000000 00e33516 146ae058 00000000 ntdll!_RtlUserThreadStart+0x1b


So, we're again faced with figuring out why we're waiting for a synchronous call to this function using buffers on the stack, but the thread is still trying to free the buffers.

After recent fixes, I don't think there's a problem with timing out the call; we just keep looping when the call takes a long time.

However, let's consider the code in the threaded function which is actually crashing:

    if( pSignalData )
    {
        if( pSignalData->hWnd != NULL )
            ::PostMessage(pSignalData->hWnd, nMsgCallsignLookup, (WPARAM)FALSE, (LPARAM)pData);
        else if( pSignalData->hEvent != NULL )
        {
            SetEvent(pSignalData->hEvent);
        }

        if( pSignalData->bFree )
        {
            delete pSignalData;	// crashes here
            pSignalData = NULL;
        }
    }



It's entirely conceivable that this code sets the event to signal the caller that work is done. At that point, Windows schedules a context switch and the waiting thread releases. It continues runing; does its work, exits the calling function and destroys the stack where the data blocks live.

Eventually, the thread in the handler is resumed and examines pSignalData. Since the calling thread's function context has changed, the pSignalData structure has fallen off the stack and is invalid. Odds are that whatever data is there shows bFree as non-zero, so we try to delete pSignalData and crash.

I've fixed the code to cache the bFree flag before signalling the event. A more thorough fix might involve cleaning up the structures used here. They're just structures, not C++ objects; accssors and methods would help encapsulate the fact that the bFree flag is proably exclusive to other settings in the structure.

The simpler fix, for now, was checked-in with this change set:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4354

PD9FER

2018-09-27 05:21

viewer   ~0006232

Sent the Beta 887 to several customers reporting the issue.
The OM I work with directly is optimistic, no more closing of LB in the past hour...
I keep you updated.

KB3NPH

2018-09-27 21:51

administrator   ~0006233

Last edited: 2018-09-27 21:52

View 2 revisions

Ticket #508543 has reported Beta V6t.4.0.887 has resoled DM and LB crashes. Good job.

KB3NPH

2018-09-27 21:59

administrator   ~0006234

Ticket #912264 has also reported the crashes have been resolved in Beta 6.4.0.877

PD9FER

2018-09-28 03:23

viewer   ~0006236

Ticket# 746825 also reported a fix.

K7ZCZ

2018-10-22 18:18

manager   ~0006331

Are these symptoms still occurring, or is can this issue be marked resovled?

PD9FER

2018-10-23 03:51

viewer   ~0006334

Yes fixed

K7ZCZ

2018-10-24 22:10

manager   ~0006346

fixed with change 4354

KB3NPH

2018-11-04 22:56

administrator   ~0006368

It appears this issue has been totally resolved according to reports from customers and my own observations on my own system. Good job Mike B. You're awesome when it comes to this stuff!!!!!
I believe this report can be closed and the folder moved to the "RESOLVED" filder in the Dumps folder.

WA9PIE

2018-11-05 11:32

administrator   ~0006371

Fix confirmed by Tim and Ferry.

Issue History

Date Modified Username Field Change
2018-08-21 11:51 KB3NPH New Issue
2018-08-22 09:25 KB3NPH Note Added: 0005989
2018-08-23 09:16 KB3NPH File Added: Multiple DBs open in Logbook Module.jpg
2018-08-23 09:16 KB3NPH Note Added: 0005995
2018-08-23 09:25 KC7FPF Note Added: 0005996
2018-08-23 20:08 K7ZCZ Note Added: 0006001
2018-08-25 12:17 WA9PIE Note Added: 0006005
2018-08-27 10:48 KB3NPH Note Added: 0006012
2018-09-07 08:20 PD9FER Note Added: 0006105
2018-09-07 09:30 PD9FER Note Added: 0006108
2018-09-11 16:09 K7ZCZ Note Added: 0006200
2018-09-11 16:09 K7ZCZ Relationship added related to 0002891
2018-09-12 03:01 PD9FER Note Added: 0006202
2018-09-13 17:47 K7ZCZ Note Added: 0006206
2018-09-14 04:00 PD9FER Note Added: 0006207
2018-09-14 08:10 K7ZCZ Note Added: 0006208
2018-09-14 09:11 PD9FER Note Added: 0006209
2018-09-17 12:39 KB3NPH Note Added: 0006212
2018-09-18 03:37 PD9FER Note Added: 0006213
2018-09-18 07:47 PD9FER Note Added: 0006214
2018-09-18 08:30 K7ZCZ Relationship added related to 0002899
2018-09-18 09:24 K7ZCZ Note Added: 0006219
2018-09-18 09:24 K7ZCZ Relationship added related to 0002900
2018-09-18 09:25 K7ZCZ Relationship added related to 0002901
2018-09-21 12:36 PD9FER Note Added: 0006228
2018-09-23 18:20 K7ZCZ Note Added: 0006230
2018-09-27 05:21 PD9FER Note Added: 0006232
2018-09-27 21:51 KB3NPH Note Added: 0006233
2018-09-27 21:52 KB3NPH Note Edited: 0006233 View Revisions
2018-09-27 21:59 KB3NPH Note Added: 0006234
2018-09-28 03:23 PD9FER Note Added: 0006236
2018-10-22 18:18 K7ZCZ Assigned To => KB3NPH
2018-10-22 18:18 K7ZCZ Status new => assigned
2018-10-22 18:18 K7ZCZ Status assigned => new
2018-10-22 18:18 K7ZCZ Note Added: 0006331
2018-10-23 03:51 PD9FER Note Added: 0006334
2018-10-24 22:10 K7ZCZ Status new => resolved
2018-10-24 22:10 K7ZCZ Resolution open => fixed
2018-10-24 22:10 K7ZCZ Note Added: 0006346
2018-10-24 22:10 K7ZCZ Project 1 - Backlog => 3 - Current Dev List
2018-11-04 07:49 K7ZCZ Fixed in Version => 6.4.0.900
2018-11-04 22:56 KB3NPH Note Added: 0006368
2018-11-04 22:57 KB3NPH Assigned To KB3NPH => WA9PIE
2018-11-05 11:32 WA9PIE Status resolved => closed
2018-11-05 11:32 WA9PIE Testing Not Started => Beta Successful
2018-11-05 11:32 WA9PIE Note Added: 0006371
2018-11-11 00:34 WA9PIE Fixed in Version 6.4.0.900 => 6.4.0.902
2018-11-11 00:34 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe