Windows Explorer abnormal end: "diffmergeshellextension

[Herters1893]

Support,

When I right click on a particular file, the Windows Explorer context menu doesn't appear and instead I get the standard "Windows Explorer has encountered a problem and needs to close" dialog.

The mini-details from the error are:
AppName: explorer.exe
AppVer: 6.0.2900.3156
ModName: diffmergeshellextension.dll
ModVer: 3.1.0.15888
Offset: 0000ae3a

Exception code: 0xc000000d
Exception address: 0127ae3a

The file I right click on is missing a "Date Created" value (it is blanks in the Windows Explorer details view). This file was created via an FTP download and apparently the download didn't set the "Date Created" attribute for the file. That's the only thing I notice about this file that is different than others that work.

I've uninstalled and reinstalled the DiffMerge shell extension (from within the DIffMerge options) and re-booted, which did not fix the problem.

I successfully use DiffMerge all the time, it is just this one file that seems to bring out the error. Copying the folder that contains the file to a new location causes the "Date Created" attribute to be filled in and then a right click on the new copy of the file brings up the Explorer context menu correctly.

Thanks for your help.

P.S.: DiffMerge is an outstanding product - thanks!

[lbauer]

Sounds like the file may be a bit corrupted. If you copy the file to another location and paste a copy back into the folder, overwriting the original, does Diff/Merge work?

[Herters1893]

After pasting a copy of the file (overwriting the "bad" file), I still get the Windows Explorer crash. The "good" copy shows both Created and Modified dates, but when I copy the "good" file over top of the "bad" file, Explorer only shows a Modified date.

I've also found that it is more than just trying to bring up the right click context menu that triggers the crash. Highlighting the "bad" file and then pressing the delete key or trying to left click the Windows Explorer "File" menu (in the menu bar) also crashes Explorer (all related, I expect). In all of these cases, it is the diffmergeshellextension.dll that shows up in the crash report.

The file itself (it is a simple text file) can be edited if I disable the DiffMerge shell extension first. When the dates are blank, doing a Properties display on the file shows the dates as: "Sunday, February 06, 1831, 8:31:13 AM"

Thanks for looking into this.

[jeffhostetler]

How strange that you can get files created without date stamps
or with such out of range dates. I tried my FTP server but couldn't
get it to fail. Which FTP client/server are you using?

Could you try zipping up the containing directory and then expand it into
another directory and see if the file is still broken in the new version?
If so, maybe you could send me a copy of the zip file, so I can do some
testing.

We'll be shipping 3.2.0 next week, give that a try and see if it is still
broken. There were a few minor fixes in the extension, but it's hard
to say if they will have any effect on this problem.

If you're interested in playing now, I've attached the shell extension that
we'll be shipping in 3.2.0. Rename/backup the version in
C:\Program Files\SourceGear\DiffMerge and put this one in its place.
You may need to uninstall and reinstall the extension from the Options
dialog, and/or close any open instance of Explorer (the dll can get
stuck in memory if Explorer or the Start Menu have it locked).

Let me know if you have any questions or problems.
jeff

[Herters1893]

Hey Jeff,

I no longer get the crash with the 3.2 release of the shell extension - thanks much.

The lack of dates on the files is because they were downloaded from an IBM "mainframe" computer (z/OS is what we call the operating system). The files are what are called "members" of a "Partitioned Data Set" in mainframe-speak. They often have creation and modification dates associated with them when they live on the mainframe, but in this case they were all "undated." The FTP client I use is found here:

www.bluezonesoftware.com/products/secure-ftp

The way I was using the FTP client apparently passed on the "lack of dates" to the PC files that got created. I agree, very strange.

When I zipped a "bad" file and then unzipped it into another folder, the file still lacked any dates but Explorer didn't crash when I accessed it. Looking at the "bad" and "good" files' properties, the create and modify dates were all bogus, but they had different bogus values.

If I were to guess, I'd guess there is arbitrary garbage in the "bad" file's directory entry for the date values - whatever was in memory when the directory entry got created (maybe the fault of the FTP client - who knows).

In any case, I no longer see any symptoms.

[jeffhostetler]

Glad to hear that the new version works for you.
Don't know how I would have debugged that one

You might post a note on bluezone website, it sounds
like there might be something funky going on there.

jeff