Windows Explorer crash always in the same directory

[Antoine]

Hello, I experience an issue always in the same directory which led Explorer.exe to crash.
I have a 3 files report generated by windows which may be useful.
What should I do to help you ?

[Antoine]

I am able to isolate the files which makes Explorer crash when PDF-ShellTools is running too.
PDF version is 1.4 (Acrobat 5.x). Hope this help you handle this.

[Antoine]

For instance, this file will make my Explorer crash : http://www.cercleinfographie.be/asbl/2009-2010/SiteWeb/FactureSiteWeb200102011.pdf
I have several other files from this provider and all crashes.
I think this could be useful to you.

[RTT]

Thanks for the sample file.
Indeed it is crashing the last public version, but I have this bug already fixed here, so expect it to be fixed also in the new version release I'm preparing.

[Antoine]

Perfect !

[itsupport@aviom]

I'm running a trial version of PDF-ShellTools v1.0.0.13 + Patch 1 on Windows 7 and running into a similar issue with Windows Explorer crashing when I edit the metatag "Title" field on some PDFs. I can easily repeat the problem on two different 64-bit Windows 7 installations, but not on a 32-bit one.  I've attached the Windows Event Viewer info for the crash.

Thanks in advance for any help you can provide on this. Let me know if you require any more info to help you troubleshoot.

[RTT]

If you can, please send me one of these PDFs that make it crash.

[itsupport@aviom]

Thanks for the quick reply, and sorry I took so long to get back to you. The holidays got in the way.

Here are two files I'm able to reproduce this error with. One of our engineers tells me she runs into this problem in various directories, but not all. We have thousands of these files on our network (that have Titles) so it could be an issue with how specific files were created or something like that.

This morning I copied these two files from our network to the laptop's local disk - the error came up again, so I think we can rule out any network/server (Windows 2003 file server) issues.

To produce the error I have Windows Explorer open and the Title field displayed as the right-most column (the only additional column other than the standard Name, Date, Type, and Size columns). I right-click each file, go to the InfoEdit tab and add my initials to the end of the text, then click OK to save the change and close the dialog. A few iterations selecting each file and editing the Title, and Windows Explorer crashes.

Thanks again!
Tom

[RTT]

Thanks for the sample files.
The problem also occurs here, and I think (fixed code is compatible with the experienced aleatory crashes) I have it now fixed. Fix will be included in this week scheduled patch release.

[itsupport@aviom]

Fantastic! Thank you for resolving this so quickly! Once I check out the updated version we'll be purchasing a site license.

A question for RTT or anyone out here - does anyone know of a script or utility to copy Windows Document Properties Titles (or other field info) over to their equivalent metatag fields? Of the thousands of files on our network there are many that only have a Title in the Windows Document Properties field. To move forward with Windows 7 we need to update the files to contain the same info in the metatag field.

If the answer is "no", it looks like I'll need to write some vbscript to do this.

Thanks,
Tom

[RTT]

Here I leave some code to start with. Just save it to a .js file, in the same directory where you have the PDFs.
Make sure you disable the PDF-ShellTools Column Handler (you can use the manager for this one), and/or the Acrobat Column Handler "...\Common Files\Adobe\Acrobat\ActiveX\pdfshell.dll", or the code will get internal PDFs Titles too, and these don't need to be set.

Code: [Select]

var WshShell = new ActiveXObject("WScript.Shell");
FMTID_SummaryInfo="{F29F85E0-4FF9-1068-AB91-08002B27B3D9}";
PID_TITLE="2";
SCID_TITLE=FMTID_SummaryInfo+" "+PID_TITLE;

function setMetadata(params) {
        //WScript.Echo( params );
        //64 bit Windows
        //WshShell.Run('"%ProgramFiles(x86)%\\PDF-ShellTools\\PDFShellTools.exe" SetMetadata ' + params, 1, true);

        //32 bit Windows
        WshShell.Run('"%ProgramFiles%\\PDF-ShellTools\\PDFShellTools.exe" SetMetadata '+params, 1, true);
    }

var objShell = new ActiveXObject("shell.application");
var objFolder2;
objFolder2 = objShell.NameSpace(WshShell.currentdirectory);
if (objFolder2 != null) {
    var FolderItems;
    FolderItems = objFolder2.Items();
    if (FolderItems != null) {
        var FolderItem;
        var Title;
        var filename;
        for (var i = 0; i < FolderItems.count; i++) {
            FolderItem = FolderItems.item(i);
            if (FolderItem.name.split('.').pop().toLowerCase() == 'pdf') {
                Title = FolderItem.ExtendedProperty(SCID_TITLE);
                if (Title) {
                    //WshShell.Popup(FolderItem.path+ '-Title:'+Title, 0, "Message", 0x30);
                    setMetadata("\"Metadata='Title=" + Title + "'\" \"" + FolderItem.path + '"');
                }
            }
        }
    }
}

[itsupport@aviom]

Update - I downloaded the new PDF-ShellTools version today. On the Engineer's Windows 7 64-bit desktop PC I uninstalled the old version and rebooted, then installed this new version. Two new issues now exist:

1. Editing document Titles now works ok, but simply right-clicking a folder in Windows Explorer causes it to crash.
2. When editing documents the Apply button remains greyed out even though a change has been made to the Title field. This occurs only when making the change via the Details tab; when making the change via the InfoEdit tab the Apply button is available.

I was able to repeat these issues on my 64-bit Windows 7 test laptop. Let me know if you need more info or details. And thanks again for working to resolve this.

[RTT]

I uninstalled the old version and rebooted, then installed this new version

You can just install it on top of the installed version.
And current installer don't even need to reboot Windows, asking user if he prefer to try restarting just the Windows Shell. May not work if the tools DLLs are in use by another, than the Shell, application.

1. Editing document Titles now works ok, but simply right-clicking a folder in Windows Explorer causes it to crash.

Indeed! But it's only happening with the trial release, that's why I missed to detect it. Until the new release, you can fix it removing this key from the Windows registry.
HKEY_CLASSES_ROOT\AllFileSystemObjects\ShellEx\ContextMenuHandlers\{E3FD95C1-D5B1-4929-B0EC-C156318EDD8F}
It will only remove the possibility to select a directory to pack in a PDF package, and you can always add it from the Create/Edit PDF package tool itself.

2. When editing documents the Apply button remains greyed out even though a change has been made to the Title field. This occurs only when making the change via the Details tab; when making the change via the InfoEdit tab the Apply button is available.

All fine here, and that Details tab is Windows Shell responsibility. But take note that, in this Details tab, the apply button state change only when exiting the edited field, so make sure you select another one to get that button state updated. In the PDF-ShellTools InfoEdit tab the state is update on every keystroke, so probably you are getting confused here because of the different behavior?

And thanks again for working to resolve this.

I'm the one who has to thank you for take the time to report the issues.