The desktop technician solved the problem himself, with the comment

There is something wrong with these files …

but didn’t realise it.

Microsoft PowerPoint XP was crashing whenever the customer was trying to open a particular set of files.

Google should have been his friend here.
aka Let Me Google That For You : Powerpoint crashes when opening file

The first link, PowerPoint crashes while opening certain presentations, has the answer.

“Since you can’t tell from within PPT whether an image was RGB or CMYK, you’ll need to go back to the source image files to verify whether this is the problem. Using PPT2003’s Save Image As feature, you could save the image as PNG or JPG, re-import it and delete the original. The presentation should then open in earlier versions of PowerPoint.”

PowerPoint does not support CMYK very well.  No surprise there.

So how do we tell if a PowerPoint file has a CMYK image in it, if we can’t open it?

If it’s a PPT file, in other words a PowerPoint 97-2003 format file, to confirm the issue we can use Notepad, and search for CMYK.

If it’s a PPTX file, in other words a PowerPoint 2007+ file, and you don’t have PowerPoint 2007, you could try the following.

1. Rename the PPTX file extension to ZIP
   –>
2. Open the file with your favourite archive program.
   
3. Search for the offending image, and replace it.  Or delete it.
   (no, I don’t know an easy way to find the offending image, sorry)
4. Rename the ZIP back to PPTX, and then that should fix your issue.

but they did.

Had a report from a user of LNME, that LNME was producing an error message, then crashing.

The cause that an message attachment had a TAB character in it’s filename, and Windows wouldn’t accept that, so it would error.
(how the TAB got into an attachment name is another question… , for another day)

Now, if you believe Windows, there is only a small number of characters it doesn’t like in file names:

… which proves to be utter tosh.  And Microsoft provides you with the proof with the Path.GetInvalidFileNameChars method.

If you use the Path.GetInvalidFileNameChars method, it will tell you there are actually 41, including both TABs.

So now, before LNME writes out the message and attachment files, LNME will now check them for more invalid characters.

What this means is …
You shouldn’t notice MUCH difference in speed, as originally I was blindly checking every filename by doing something like this:

If FilenameField <> “” Then
‘Trim Leading and Trailing space from FilenameField Field
FilenameField = FilenameField.Trim

FilenameField = Replace(FilenameField, “/”, “[SLASH]“)
FilenameField = Replace(FilenameField, “\”, “[BACKSLASH]“)
…
End If

Now I check first to see if the FilenameField has invalid characters, and if so, then do the replacement of “invalid” characters.

‘ get the list of invalid characters for this operating system
cInvalidFileNameChars = System.IO.Path.GetInvalidFileNameChars

‘ check if any of the invalid characters are in our FilenameField
iReturnValue = FilenameField.IndexOfAny(cInvalidFileNameChars)

‘ >0 means that we found some invalid characters.
If iReturnValue >= 0 Then
If FilenameField <> “” Then
‘Trim Leading and Trailing space from FilenameField Field
FilenameField = FilenameField.Trim

FilenameField = Replace(FilenameField, “/”, “[SLASH]“)
FilenameField = Replace(FilenameField, “\”, “[BACKSLASH]“)
…
End If
End If

The performance improvement appears because the majority of Subject and Attachments are correctly named, so the previous blind check will be skipped.

You can download the fixed LNME, here.