RasterIO.dll stack dump when deleting a raster file on disk with .Delete() - C#

446
3
07-26-2011 06:51 AM
FrankMcLean
New Contributor III
Hi,
I have migrated our Desktop extension from 9.3 to 10 - C# using VS2008, deployed on Windows XP Pro, SP3.  I am getting the following crash, when the software tries to delete a raster file on disk using .Delete():

Problem signature:
  Problem Event Name: BEX
  Application Name: ArcMap.exe
  Application Version: 10.0.2.3200
  Application Timestamp: 4d9bad9f
  Fault Module Name: RasterIO.dll
  Fault Module Version: 10.0.2.3200
  Fault Module Timestamp: 4d9b750a
  Exception Offset: 00035690
  Exception Code: c0000409
  Exception Data: 00000000
  OS Version: 6.0.6002.2.2.0.272.7
  Locale ID: 1033
  Additional Information 1: f3fb
  Additional Information 2: 76cb28eb10e2a4f22903a981f9d7609e
  Additional Information 3: 39e6
  Additional Information 4: e6c1cee561b673e1a7d4d2f425db536e

Searching the forums, it looks like a similar problem has been reported when there are spaces in the raster path - in this case there are definitely not.  The odd thing is that the crash happens after a call to .CanDelete() is successful:

IRasterDataset rasterDS = this.openRasterDataset(); 
IDataset dataset = rasterDS as IDataset; 
if (dataset != null)
{
      if (!dataset.CanDelete())
     {
           return false;//can't be deleted
      }
      dataset.Delete();


The crash happens during the .Delete() call.

Can anyone please help?  I can't trace this any further.

Thanks,
Frank
0 Kudos
3 Replies
PaulDodds
New Contributor
I have encountered the same error in the same module when trying to load an MXD created by 9.3.1.  The error is:

Problem signature:
  Problem Event Name: BEX
  Application Name: ArcMap.exe
  Application Version: 10.0.2.3200
  Application Timestamp: 4d9bad9f
  Fault Module Name: RasterIO.dll
  Fault Module Version: 10.0.2.3200
  Fault Module Timestamp: 4d9b750a
  Exception Offset: 00029966
  Exception Code: c0000409
  Exception Data: 00000000
  OS Version: 6.1.7601.2.1.0.256.48
  Locale ID: 2057
  Additional Information 1: 74e1
  Additional Information 2: 74e15f4f78a355b516e5b2310fdbf823
  Additional Information 3: 35e3
  Additional Information 4: 35e3ee204c726c40df39cbfda05d377e


This error causes ArcMap, ArcCatalog and, unbelievably, even the MXD program to crash.  I've attached the MXD with the problem.  I know that other people have had similar errors caused by spaces in raster names but I don't think I have this problem (although I can't check because I no longer have access to 9.3.1 so I have no way of opening the file).

Can anyone help?  Are there any plans to fix the problems in this module?

Thanks,

Paul
0 Kudos
FrankMcLean
New Contributor III
Hi,

This sounds like it might be related to a confirmed newly created bug within ArcGIS 10 - Bug Report Number NIM071209, although my issue happens specifically when a raster is deleted, not simply loaded.

I should have reported the 'resolution' to the forum - my apologies.  I guess I thought this official report would show up in other searches.  I'm quoting below the full 'shake-out' of the issue I received from esri support.

Basically (when deleting), if your raster pathname is too long, you get a stack dump.  If it's a little shorter, you get a thrown exception.  If it's short enough, all is well.  Lengths are in the quoted response below in the Steps to Reproduce section.  Note that Tiffs don't show this issue.

I suggested that an 'OS delete' of the raster might be possible as a workaround, but the intertwined nature of the various supporting files means that there is a great danger of corruption, unless you only have one raster in your workspace, when you could just delete the directory.

Hope this helps.

Thanks,

Frank

Frank,

I have submitted the below bug report since the issue did not exist in ArcGIS 9.3/9.3.1 thus I have determined the pathname length issue is not by design but rather a bug.  Please consider using less lengthy paths.  As this issue still needs to be evaluated by our development team, I cannot provide a known length that you can count on. 

In the meantime, please consider staying within the 106 folderName length you have observed, but also within a total of approximately 114 characters, which includes the dataset name itself (106 folderName + \ + 8 datasetName = 115).  The known limit for a GRIDs dataset name is 13 characters, thus, if you go up to 13 characters for the dataset name, account for this in the folderName such that the total folderName and datasetName is approximately 115:
LINK:
http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//009t0000000w000000

Frank, I will now close this support incident.  Please use the bug report number to track the progress of the bug from this point forward, as well as to escalate the bug report if you would like to do so.  The best place to get this information is from the "My Support Portal", available through a link on the Support Services website at:
http://support.esri.com
or you can go directly to the "Esri Customer Care Portal" here:
http://Customers.esri.com


Bug Report Information
----------------------
Bug Report Number:  NIM071209

Synopsis:
In ArcGIS 10, deleting an Esri GRID in ArcCatalog or with IDataset.Delete() will either produce an error or will crash the application when directory path is beyond a certain length.

Long description:
In an ArcGIS Engine 10 console application, deleting an Esri GRID raster file with IDataset.Delete() will either result in a thrown exception at IDataset.Delete() or the console application will crash after IDataset.Delete() is called.  It has been observed that this occurs beyond a given length of the directory path or file name path where the GRID is stored on disk.  The same is produced in ArcCatalog or with ArcMap's Catalog window, where either an error or application crash occurs when attempting to manually delete within Catalog.

Note 1:
Testing in ArcGIS 9.3.1 SP2 with the same GRID raster and same length in directory/file path does not produce the issue, only in version 10 of ArcGIS.  Although a crash in ArcGIS 10 may also be seen when attempting to add or paste a GRID to the same folder location where the Delete causes a crash or exception, customers may be working with GRIDs that were already located in that location prior to version 10 so now they have to modify the location of these files and their source code.

Note 2:
Testing in ArcGIS 10 with a .tif (TIFF) instead of a GRID does not produce the issues.

STEPS TO REPRODUCE:
1.  Open EngineConsole950753.sln (ArcGIS Engine 10 console application)

2.  Prepare to copy the attached GRID file, compati1, to the three different directory locations that will be tested in the subsequent steps.  Please create those directories in Windows Explorer as needed.

3.  Test/Start debugging the first directory path location with folderName length of 137:
"C:\Projects\usfws\EasternShore\Vista_EasternShore\GIS_Datasets\Scenarios\Current_Landuse_Baseline\Evaluations\Baseline_Ecological_Systems"

= console application will crash after calling IDataset.Delete() method.  Attempting to manually delete the same in ArcCatalog or ArcMap's Catalog window will cause ArcCatalog or ArcMap to crash, as well.

4.   Test/Start debugging the first directory path location with folderName length of 109:
"C:\Projects\usfws\EasternShore\Vista_EasternShore\GIS_Datasets\Scenarios\Current_Landuse_Baseline\Evaluations"

= IDataset.Delete() will throw the following Exception: 
"Exception from HRESULT: 0x8004101B"
Attempting to manually delete the same in ArcCatalog or ArcMap's Catalog window will cause ArcCatalog or ArcMap to display an error message box with the following message:
"Failed to delete selected object(s)"

5.  Test/Start debugging the first directory path location with folderName length of 97:
"C:\Projects\usfws\EasternShore\Vista_EasternShore\GIS_Datasets\Scenarios\Current_Landuse_Baseline"

= IDataset.Delete() method successfully deletes the GRID file. Also, deleting the same GRID file in ArcCatalog or ArcMap's Catalog view does not produce any issues.
---

Regards,

Edgar B.
0 Kudos
PaulDodds
New Contributor
Hi Frank,

Thanks for the note.  In the end, it was easier just to rebuild the files from scratch.  I will look forward to the patch!

Thanks,

Paul
0 Kudos