Win10 update to version Creator

[.Paul.]

Dear Reader of this post,

If you are reading this because your OpenCPN will not close after it puts diagonal hatching over the chart canvas and it just waits, there are suggestions ("workarounds") for getting it to close near the end of this post.

Windows Update installed the Windows 10 Creators Update on my notebook computer on June 15, 2017. Since that update, OpenCPN fails to close (exit) if

OpenGL is enabled and one or more of the these are active:

    GPS position sentences are being received from a serial port.

    AIS sentences are being received from a network connection.

    The VDR plugin is playing recorded GPS and AIS.

    A Guard Zone is set in the Ocpn_Draw plugin.

There may be more cases than listed above that cause OpenCPN to fail to close.

This is reported in Flyspray #2256.

https://opencpn.org/flyspray/index.p...256&project=77

I have found this problem in OpenCPN release packages for Windows from 4.2.0 through 4.6.1 and in the current (25 Jul 2017) Beta 4.6.2. OpenCPN 4.0.0 does not seem to have a problem with closing after Creators Update.

I have not seen any other reports of this problem with OpenCPN not closing. It might be related to my computer having a dual core processor.

Windows System Information:

OS Name                         Microsoft Windows 10 Home
Version                         10.0.15063 Build 15063
Other OS Description            Not Available
OS Manufacturer                 Microsoft Corporation
System Name                     TOSHIBA
System Manufacturer             TOSHIBA
System Model                    Satellite C55-A
System Type                     x64-based PC
System SKU                      PSCF6U
Processor                       Intel(R) Pentium(R) CPU 2020M @ 2.40GHz, 2400 Mhz, 2 Core(s), 2 Logical Processor(s)
BIOS Version/Date               Insyde Corp. 1.20, 6/7/2013
SMBIOS Version                  2.7
Embedded Controller Version     1.30
BIOS Mode                       UEFI
BaseBoard Manufacturer          TOSHIBA

These are the usual signals that are made from the keyboard or pointing device that should cause OpenCPN to save settings and navigation data and to close its window as it releases memory and other resources to Windows system:

(1) Click on X in top-right corner of the window.

(2) Click on the OpenCPN icon in the top-left corner of the window and select "x Close" from the drop down menu.

(3) Key Alt+F4.

(4) Key Ctrl+Q.

(5) Use the menu (key Alt if the menu is hidden) and select "Navigate" and "Exit OpenCPN".

When one of these signals to close is made by the operator, the chart canvas and Chart Bar (piano) is diagonally hatched as usual, but the Tool Bar is not hatched. OpenCPN does not close. It just waits and waits and...

Here are some work-arounds that can be used to close or exit OpenCPN without loss of changes in settings (opencpn.ini) or tracks, routes, waypoints, etc. (navobj.xml). These can be tried after the operator has signaled the program to close as described above, and the chart canvas is diagonally hatched, but the program does not close.

(1) Use the Alt key to activate the menu. Wait one or two seconds. Key Alt again and OpenCPN should exit after saving settings and data. If it does not exit, try keying Alt and Alt with a little more or less time in between. This always works for me, and none of my settings or connections has to be restored.

(2) Since the Tool Bar is still active, select Options (wrench) > Display > Advanced and remove the checkmark from the "Use Accelerated Graphics (OpenGL)" and click "OK". OpenCPN should exit. You might want to enable "Use Accelerated Graphics" next time you run OpenCPN.

(3) Use Options > Connections and remove the checkmarks in the "Enable" column of the "Data Connections" box and click "OK". You will have to put the checkmarks back next time.

(4) If the GPS or AIS data feeds into the computer via USB cables, unplug these from the computer. If a wireless network feed is used, switch to airplane mode to interrupt the feed. If an ethernet cable is used, unplug it. OpenCPN on my computer completes the close operation a few seconds after the GPS and AIS feed is interrupted. Don't forget to reconnect the cables and to switch airplane mode off.

(5) If the VDR is playing back a recording, switch it off using the icon on the Tool Bar.

Don't use the Task Manager to stop OpenCPN with "End Task". That will cause OpenCPN setting changes, new tracks, routes, etc. to be discarded. Also, don't have Windows shut down the computer for the same reason.



Paul

[transmitterdan]

Paul,

Please check your PM inbox.

[CarCode]

Originally Posted by transmitterdan

Paul,

Please check your PM inbox.

Don't know why this is hide to other bothered Windows users. It is simply another bug in the OpenCPN software and seemed to be fixed in one of the next releases.

Gerhard

[transmitterdan]

Gerhard,

It is not to hide anything. It is a private conversation that would not be helpful to anyone else.

[transmitterdan]

All,

I can reproduce this in a Debug build for Windows 10. The method I used was to send lots of NMEA data at O. The message rate was about 100 NMEA messages per second via an IP connection. As long as the messages keep coming O will not close. It shows the diagonal hash on the chart viewport. But when it reaches the first Yield() during closeout function then it hangs trying to empty the event queue. But it can never get it empty so Yield() does not return so the close out can complete.

I think this has something to do with Creator's update to Windows 10. Perhaps Microsoft improved throughout on IP streams or perhaps they reduced performance in OpenGL. I am working on a fix so feel free to drop more hints about what is running and what you see in the screen. For example, when it will not close do you see anything change in the Dashboard or the status bar such as GPS coordinate changing. Any hints or observations appreciated.

[AedanC]

I don't think it's IP specific, It happens on my boats system which has no IP streams, only serial NMEA 0183 comms.

[CarCode]

I know nothing about Windows (using Macs) but there was a commit some days ago in the sources:
"Correct crash on Windows exit while OCPN is still running." Commit #2adc333

#ifdef OCPN_USE_CRASHRPT
#ifndef _DEBUG
// Uninstall Windows crash reporting
- crUninstall();
+// crUninstall();
#endif
#endif

Hopefully this will fix the bug.

Gerhard

[.Paul.]

Originally Posted by transmitterdan

All,

...

I think this has something to do with Creator's update to Windows 10. Perhaps Microsoft improved throughout on IP streams or perhaps they reduced performance in OpenGL. I am working on a fix so feel free to drop more hints about what is running and what you see in the screen. For example, when it will not close do you see anything change in the Dashboard or the status bar such as GPS coordinate changing. Any hints or observations appreciated.

I don't recall any problems where OpenCPN failed to close with diagonal hatching on the screen before Windows 10 Creators Update was installed on my notebook.

In my post #16 in this thread, I noted that OpenCPN fails to close if OpenGL is enabled and a Guard Zone is set in the Ocpn_Draw plugin. I did not have any active serial or network connections.

This morning I found two more cases where OpenCPN fails to close if OpenGL is enabled and connections are not active. Here is a picture of the Connections dialog.



OpenCPN 4.6.2 Beta fails to close if OpenGL is enabled and "Navigate to Here" is selected from the right-click menu. Here is a screenshot made a minute or more after I clicked on the "X" in the top-right corner of the window.



I closed O by keying Alt and keying Alt again after the Menu Bar was displayed. I tried this same "Navigate to Here" sequence with OpenCPN 4.2.0 Release. It also fails to close until I use the Alt to open the menu and Alt to close it. I also tried this with the OpenCPN 4.0.0 Release, but it clears "Navigate to Here" immediately after I select it.

OpenCPN 4.6.2 Beta and 4.2.0 Release fail to close with OpenGL enabled and "Set Anchor Watch" selected from the menu that appears with a right-click on a near-by mark. The two-bell alarm sounds repeatedly (probably because positioning sentences are not being received) Here is a screenshot made some time after I clicked on the "X" in the top-right corner of the window.



The Alt wait Alt technique closes OpenCPN. I also tried setting the Anchor Watch in OpenCPN 4.0.0 Release. It (4.0.0) closes promptly after I click on the "X" in the top-right corner. I did notice that this older version did not alarm for the missing position reports.

Paul

[.Paul.]

All,

In my post #23, above, I noted that I was unable to use "Navigate to Here" without a GPS connection in OpenCPN 4.0.0 Release. I tried that again, the reason "Navigate to Here" closed immediately was that the "Here" point was so close to the boat that it had already arrived. I just tried it again, with more distance between the boat and the destination. It worked as it should with "This Leg" column on the right side of the chart canvas. When I clicked on "X" in the top-right corner, OpenCPN closed as it should.

OpenCPN 4.2.0 Release and OpenCPN 4.6.2 Beta (25 Jul 2017) fail to close when "Navigate to Here" is active. It fails with or without active Connections.

Paul

[transmitterdan]

Paul,

This is good information. It helps identify the conditions. I think it still has to do with the event queue getting flooded. I think navigate to hear causes a stream of events to be created providing XTE information.

[.Paul.]

Here are some more observations running OpenCPN 4.6.2 Beta (25 Jul 2017) in Win10 Creators Update. After initiating the Close by clicking on the "X" in the top-right corner there is a short delay before the diagonal hatching appears on the chart canvas. After that, everything seems to work in O except it is very slow.

Toolbar icons including the menu under Options work.

GPS and B&G NMEA 0183 serial feeds are received and changes show on Status Bar and dashboard.

Status Bar shows rotating line on the left (| / - \ ...)--about 4 seconds between line directions. The GPS Lat and Lon updates in fourth decimal place of minutes (boat is in slip in marina). SOG shows 0.40 kts and COG shows 322 degrees. SOG is obviously wrong because SOG and COG have not changed for half an hour and the screen on the GPS reads 0.0 kt. The cursor Lat, Lon, Bearing and Range update a second or more after I move the cursor. Frames per second stays at 0 fps.

All the observations above are after the hatching overlays the chart canvas.

Paul

ps. I just noticed that COG updated to 215 degrees, but SOG is still 0.40 kts.

[Hakan]

Another Creator report:

My Win10 on a dated HP 8460p was today automatically updated to "Crowdin".
OCPN 4.6.2 by yesterday's build from Github.

No problem noticed! (Apart from oeSENC-fpr but that's another story.) OCPN is nicely closed and IP/Serial NMEA connections was closed in 1 sec as usual.
My portable instance is also fine. That O 4.6.2 was built 25 July.

When sailing season ends here I may connect my Nav-PC to Internet again. That Lenovo PC was forced updated to Crowdin in "beforehand" and the problem I experienced at the time was the initiator of this thread.

Håkan

[transmitterdan]

Originally Posted by CarCode

I know nothing about Windows (using Macs) but there was a commit some days ago in the sources:
"Correct crash on Windows exit while OCPN is still running." Commit #2adc333



Hopefully this will fix the bug.

Gerhard

This has to do with the installer. It just uninstalls the crash reporter program before installing a new version. Nothing to do with the Windows 10 issue being discussed.

[CarCode]

Originally Posted by transmitterdan

This has to do with the installer. It just uninstalls the crash reporter program before installing a new version. Nothing to do with the Windows 10 issue being discussed.

You might want to read the sources a little bit. This code change is part of the function "MyApp::OnExit()" and therefor seems to be the reason for the hang. In no way "It just uninstalls the crash reporter program before installing a new version."

Gerhard

[transmitterdan]

Originally Posted by CarCode

You might want to read the sources a little bit. This code change is part of the function "MyApp::OnExit()" and therefor seems to be the reason for the hang. In no way "It just uninstalls the crash reporter program before installing a new version."

Gerhard

Gerhard,

Ok, thanks for correcting me. I misread the file name as part of the installer scripts. I will see if that fixes anything since I can reproduce the hang in Windows 10. Sorry for misreading the name of the file.