ThinkGeo.com    |     Documentation    |     Premium Support

Map is delaying the process to close

Hi

I have an application using the ThinkGeo for WPF 14.3.2 in one of its child windows. When the application is closed then I can see in the Visual Studio Diagnostic tools (and in Windows Task Manager when running the release build) that the application is still running in the background for 8 ~ 10 seconds when the main windows is closed.

I have disabled the animation in the map.

I have a demo illustrating the problem. The demo was made for another post, but it can also be used this case.

When the application is running:

3 ~4 seconds after the application is closed

Finally the memory is slowly released and the process is terminated:

My demo application used in the screenshots:
DemoMapStealingFocus_2025_08_27.zip (20.8 KB)

Any suggestion how I can resolve the problem ?
Thanks

Best regards
Domenico

Hi Domenico,

You need to cancel the map refresh in the timer thread when closing the window. The following code will do the trick(MapWindow.xaml)

    this.Closing += MapWindow_Closing;

     private void MapWindow_Closing(object? sender, System.ComponentModel.CancelEventArgs e)
     {
         Map.CancellationTokenSource.Cancel();
     }

Thanks,
Ben

First_video.zip (3.9 MB) Hi Ben

Tanks for you code.
I applied your suggestion in the demo application, but it is not helping.
In the demo I have added this method on the Map Window:
> private void Window_Closing(object sender, System.ComponentModel.CancelEventArgs e)

    {
        System.Diagnostics.Debug.WriteLine("!!! Closing the MAP view");

        m_Timer?.Change(Timeout.Infinite, Timeout.Infinite);
        m_Closing = true;
        Map.CancellationTokenSource.Cancel();
    }

In order to avoid any extra timer invocation, I stop also the timer, and I set a Boolean flag to prevent the refresh method to be called in the timer callback.
This is not helping.
I have made 2 videos illustrating the behavior.
I the first video I close the demo application, and you can see that it takes few seconds from the view is closed and the process is terminated.

First_video.zip (3.9 MB)

I the second video I close the Map Window before I close the demo application. Therefore, the closing event on the Map Window is executed and any map refresh should be cancelled but it is still taking time.

Second_video.zip (3.4 MB)

Furthermore, we have noted that the demo application terminates with the following line in Visual Studio Output Window:
The program ‘[33604] DemoMapStealingFocus.exe’ has exited with code 3221225477 (0xc0000005) ‘Access violation’.
This happen regardless of when the map windows is closed (when the application is closing or only the map window is closed).
Best regards
Domenico

One more comment. In all the cases we have used a raster map (ECW) as the background overlay in the mapview control. The delay and the (0xc0000005) ‘Access violation’ is not observed if using a GeoTiff as background or no-maps in the background

HI Domenico,

  1. You mentioned earlier that it was “still running in the background for 8–10 seconds when the main window is closed” , but in the videos it only keeps running for a couple of seconds before the debug tool closes. Does that mean Map.CancellationTokenSource.Cancel(); has improved the behavior?

  2. I wasn’t able to reproduce the issue on my side, but that may be because the demo you sent doesn’t include the background image. Since it uses GDAL to render the ECW, which cannot be canceled immediately, could you verify whether the issue disappears when the background is not loaded?

Thanks,
Ben

Hi Ben

It is random about how long time it will take.

I can confirm that the behaviour is only observed when using ECW and I sometimes GeoTiff.

In addition to the exception 0xc0000005 sometimes we got also the exception 0xc0000374 crashing the application.

We found a way to reproduce the exception. I have made a new Demo where I have removed all the extra items which are not needed for the fault.

DemoRasterMapCrash.zip (966.3 KB)

This demo is including the ECW used during the test.

If the Map is open with the ECW then showing and hiding the grid different times (in a relax tempo) make the demo crashing with the exception 0xc0000374. Sometimes it was crashing after 3 ~4 times for me other times after 20 times.

We have not observed the crash if no-maps in the background is loaded.

I have made a video about the crash. You can find the video at: https://we.tl/t-HI8ZlqcrCf

Best regards
Domenico

Hi Domenico,

You don’t need to call m_OverlayGrid.RefreshAsync() after setting m_OverlayGrid.IsVisible. Remove m_OverlayGrid.RefreshAsync() and everything will be fine.

We will keep digging in and see why that exception is thrown.

Thanks,
Ben

Hi Ben

Thanks. I will remove the call m_OverlayGrid.RefreshAsync().

RefreshAsync make easy to provoke the exception 0xc0000374 which should never happen.

Is there any other way I can show the ECW raster files?

In the current ThinkGeo implementation it is my understanding that several API are involved in the process: ThinkGeo -> GDAL -> ERDAS.

Is there any implementation which is going directly ThinkGeo -> ERDAS without having the extra GDAL API in between?

Best regards

Domenico

Hi Ben

What is the status about this item ?
The application is still taking some seconds when closing and terminating with the following exception in the debugger output view:
The program ‘[27016] Dispatcher.exe’ has exited with code 3221225477 (0xc0000005) ‘Access violation’.

Sometimes the application is crashing with the exception: 0xc0000374:

Faulting module name: ntdll.dll, version: 10.0.19041.6093, time stamp: 0xd1cd3808
Exception code: 0xc0000374
Fault offset: 0x00000000000ff3c9

The exceptions 0xc0000005 and 0xc0000374 are observed when the map is open with an ECW raster map (as also illustrated in the demo).
Our application is closing OK if the map is shown with a GeoTIFF raster map.

Best regards
Domenico

Hi Domenico,

Do you see this issue anymore when showing/hiding the graticule overlay after removing the call m_OverlayGrid.RefreshAsync()? Does the issue now only happen when closing the window?

You mentioned this issue in a handle leak post, so does it have anything to do with handle leaking?

And it’s always through Gdal, no direct way from ThinkGeo to ERDAS.

Thanks,
Ben

Hi Ben

After I have removed the RefreshAsync then it is very difficult to get the exception 0xc0000374

The exception 0xc0000005 when closing the application is still present (also the delay).

I believe that the 2 exceptions are related but I have no evidence for that.

The exceptions are primary raised when working with ECW raster files.

Randomly (not so often) I got the 0xc0000374 also with GeoTIFF. Last time I was testing with an 8 GB GeoTiff.

Note RefreshAsync helps to trigger the error, but regardless of the RefreshAsync method, the exceptions 0xc0000374 and 0xc0000005 should not happen. This is a fault which we need to address.

Sorry to mention this entry in the handle leaking case. The reason for that is that this problem (exceptions 0xc0000374 and 0xc0000005) has been observed after we upgraded from 14.2.6 to 14.3.2 when solving the handle leaking case.

We did never observe those exceptions before when using ThinkGeo version 14.2.6

Best regards

Domenico

Hi Domenico,

  1. Please try pulling the latest beta(ThinkGeo.Gdal 14.4.0-beta084). It includes a fix for the crash that could occur when hiding/displaying the graticule overlay in your original demo (even before removing RefreshAsync() or applying other optimizations). The root cause was that GdalProjectionConverter is not thread-safe. We’ve fixed this internally by locking the critical code. As an alternative workaround, you can also switch to the managed ProjectionConverter .
  2. Regarding the exception you see when closing the application ( 0xc0000005 ), this is due to GDAL resources not being fully released at shutdown. You can resolve it by adding the following call in your Window.Closing event:
OSGeo.GDAL.Gdal.GDALDestroyDriverManager();

This will force GDAL to release its global resources and should prevent the exception.

Let me know if it works.

Thanks,
Ben

Hi Ben

After the first quick tests it seems that both suggestions are working.

About item 1: the crash with RefreshAsync
I tested my demo application (which was crashing before) with both suggestions:
a) Using ThinkGeo version 14.4.0-beta085
b) Using ThinkGeo 14.3.2 and replacing GdalProjectionConverter with ProjectionConverter
In both cases I was not able to make the demo application crash. I will update my main application and perform more tests, but the first impression is that it is working.

About item 2: delay and exception when closing
The code OSGeo.GDAL.Gdal.GDALDestroyDriverManager(); added in the windows closing event seems to resolve both the delay and the exception (0xc0000005) when closing.

Note that since I am showing the raster map in a child window I had to call the method in closing event of the main window. If the GDALDestroyDriverManager is called in the closing event of the child window then ThinkGeo will raise the following exception next time the child windows is open again:

Error opening the raster file: D:\Test\DemoRasterMapCrash\DemoRasterMap\bin\Debug\net9.0-windows\Maps\Sonderborg_ECW_Test.ecw
System.ApplicationException: No driver registered.
   at OSGeo.GDAL.Gdal.Open(String utf8_path, Access eAccess)
   at ThinkGeo.Core.GdalRasterSource.OpenCore()
   at ThinkGeo.Core.RasterSource.Open()
   at DemoRasterMap.MapWindow.Discover(String _filename, String& _projection, String& _worldFile) in D:\Test\DemoRasterMapCrash\DemoRasterMap\MapWindow.xaml.cs:line 1326

At the moment seems that both issues are solved by the suggestions. It seems they was 2 separate issues.

It is my plan to add the call OSGeo.GDAL.Gdal.GDALDestroyDriverManager() in the main windows closing event, to replace GdalProjectionConverter with ProjectionConverter and to continue with ThinkGeo version 14.3.2 (instead of wait for 14.4) in order to be able to release an hotfix as soon as possible.

Thanks for the help

Best regards
Domenico

Hi Domenico,

Glad to hear it works, and thank you for the detailed explanation!

We’ll see if there’s a better way (create a new API or something) to deregister/re-register those gdal dependencies in the future versions.

Thanks,
Ben