After adding handler for pdf windows explorer crashes

[jmarkotic]

Hi, i added handler (simple profile) for *.pdf. And I can edit tags for pfds from WinExplorer. When I add tag, search for tag, or maybe not doing nothing, Windows explorer crashes after certain i time and restart itself. I confirmed this is due to pfdf handler. As soon as i remove it, WE works just fine. I have Win10 patched pretty much to the latest. Any idea how to solve this ?

[Dijji]

How did you confirm that the File Meta handler was to blame?

A particular puzzle is how File Meta might be affecting Explorer when you are taking no action within Explorer. Crashes only occur when code is invoked, and Explorer only invokes File Meta at three points: when using the context menu to export or import properties; when you open a folder containing PDF files, when Explorer will read their properties; and when you look at the properties of a specific PDF file, when Explorer will read its properties.

Explorer runs no background tasks which might cause random crashes.

I have thought of one risk, which ought to be closed up. If you uninstall File Meta, then you ought to use the Association Manager to remove the File Meta handler before you uninstall File Meta itself, so as to restore the functionality of the original handler.

The only other evidence I have is anecdotal. I have been running all my Windows 10 computers with the File Meta property handler installed for PDF files ever since the 1.6 release came out, with no problems of the sort you report.

Of course, I accept that this does not prove File Meta is not at fault. However, it does mean that I would appreciate it if you could supply as much more detail as possible about the problems that you are having and why you think the evidence points at File Meta.

Dijji

[jmarkotic]

Hi,it is not FileMeta who is crashing, but installed handler for pdf. Here are the steps that would crash explorer: -create handler for pdf -edit properties of some pdf file by adding tags - I usually add multiple tags -after certain period of time explorer would be restarted -I could provoke crashing by starting search with tags "searchbox tag:something", multiple times

after removing tag handler, explorer would behave normally (with FileMeta still being installed). Let me know if I can help anyhow on chasing this. This pdf handler functionality (for adding tags) would really be useful to me. I tried this on corporate laptop with Win10 (nothing specific on it). I might also try this on some other laptop/tablet. All files are syned with OneDrive.

[Dijji]

Thank you for the offer of help.

As I'm not seeing this on any of my computers, what I think I would like to do is to build a special release with a heavily instrumented property handler that will produce a log of everything you do, and try to intercept any crashes that arise and log them too.

Don't worry, the only way I will ever get to see any of the contents of the logs is if you do me the favour of copying the contents into this Issue thread, so you will know exactly what I see.

So the idea would be to install a special release, and when you wanted to start logging, delete the log file, reproduce the problem, and if successful, copy the contents of the newly created log file into this thread.

Does this sound okay to you?

If so, it will take me a few days to prepare the special release, but then we can try and track this problem down.

Dijji

[jmarkotic]

Hi, yes, I will be happy to assist with specific version to provide more logs. Waiting inputs from you then on when to proceed. j

[Dijji]

I finally have a fully instrumented property handler. I had forgotten just how hard the low-level Windows APIs make a programmer work!

The plan is to package it as a new release, so you install it by uninstalling File Meta as a whole, then installing the instrumented version, and similarly to go back to the standard release.

Before I make the release, however, I need to check couple of things.

Firstly, are you running a 64-bit system? If so, I will only prepare a 64-bit instrumented release.

Secondly, the property handler is hardcoded to write its log files in a folder called 'c:\FilemetaLogs' It will create this directory automatically. Do you have an accessible C drive for it to create the folder in on your system?

If you let me have these answers, I will create the release package appropriately.

The instrumentation, by the way, records two things: all exceptions that occur anywhere during a call into the property handler; and the parameters given to and the values returned from all property access functions that are invoked.

I will include some more details about how to work with the instrumented release in its release notes.

Dijji

[jmarkotic]

Hi, i confirm on all: it's Win10 64bit and have accessible C drive with permissions. Waiting for new release then.

[Dijji]

I have now posted release version 1.6.0.1. Please let me know what you find out!

Dijji

[jmarkotic]

log_2020-05-03 - Copy (2).log Log attached. file explorer chrashed few times - while tagging or accessing pdf files.

[jmarkotic]

let me know if i would need to provide more logs.

[Dijji]

Thank you!

Looking at the log, no crashes are being recorded. As far as I can tell, the lifetime of the property handler runs smoothly from Initialize to final release in every case.

Would it be possible to reproduce the crash again, but this time to take a copy of the last few lines of the log immediately after the crash has occurred to see if an instance of the property handler is active at the time of the crash?

Do you find it as spooky as I do seeing all your activities carefully recorded by the computer? It makes me wonder what all these browser trackers are up to.

Dijji

[jmarkotic]

Well, as said - it is not Filemeta being crashed, but explorer. I should maybe open ticket with MS. I will try but it is weird - explorer does not die at some point of time when I am doing something, but some 10-20s later. As for logs, I would access&tag 1-2 pdf files (and I see those in ogs), but in logs it would show lot of other files which I didn't access at the time.

[Dijji]

True, but if it is File Meta causing the crashes, then the natural expectation is that some File Meta code would be running at the time. However, it seems increasingly that this is not the case. Thoughts then turn to the question of what could File Meta be feeding Explorer that gave it delayed indigestion? The log for the period running up to the crash might give us a clue.

You are seeing a lot of activity for files you are not touching because Explorer will read meta data for many if not all of the files in a folder when you open it. These will be GetValue operations. You'll find that the update operations, using SetValue, are much rarer and correspond to things which you have actually done.

Dijji

[Dijji]

In the absence of more evidence, I have been using my imagination.

The delayed action of the crash implies some sort of memory corruption that is only causing trouble when the relevant memory is accessed a little later. So I have been going through the property handler removing every possible touch on Explorers memory. I did not find anything that should not be fine - but in the main lines, such as reading and updating properties when no errors occur, I now make no changes at all to memory owned by Explorer. All the necessary changes are now made by Windows operating system code that would be running anyway if the File Meta property handler was not installed.

So please give version 1.6.0.2 a go and let me know if it makes a difference. If not, the tail end of the log from before the crash would be appreciated, as I am now also recording a little more information.

Dijji

[fraxyz]

If it can help on Win7 64bit windows explorer and also xyplorer are crashing for me when adding fields to pdf. Nothing noteworthy noted in logs.

[Dijji]

I have now posted version 1.6.0.3, which closes off a few more imagined possibilities, and again improves logging. If anybody experiencing these problems could give it a try and see if it sheds any light I would be grateful. I think that this is the last of this series: I really am struggling to think of any other way that I could be giving Explorer any problems.

Obviously, the few lines in the log with timestamps nearest to the time of the crash are the ones of most interest. In fact, I haven't yet seen any log entries claimed to be from around the time of a crash, so anything you have would be of interest even if it looks innocuous.

Dijji

[Dijji]

Another possibility has occurred to me. Is this a problem with the C runtime installed on your system?

The C++ components of File Meta depend on the 2010 version of the C runtime. This should be installed as "C:\Windows\System32\msvcr100.dll". On my system, the version is 10.0.40219. On 64-bit systems, File Meta also uses a 32-bit version of the library, because the 64-bit File Meta also installs a 32-bit version of the property handler for 32-bit programs (typically Office) running on the 64-bit system. This 32-bit version should be installed as "C:\Windows\SysWOW64\msvcr100.dll" with the same version number.

Of course, these files should not be installed by hand. If you look in your installed Apps, you should find "Microsoft Visual C++ x64 Runtime - 10.0.40219" and "Microsoft Visual C++ x86 Runtime - 10.0.40219" (with the same version number as the dll).

Because File Meta depends on this runtime, the runtime installation is bundled as part of the File Meta installation, and will be invoked when File Meta is installed. The 64-bit File Meta installation will install both the 64-bit and 32-bit C++ runtimes.

However, this does not guarantee a good outcome, because if msvcr100.dll is already present on the system, then the C++ Runtime installer will not overwrite it. I did have one case where the user had tried to run another program that needed the same runtime that failed because it was not installed. So the user enterprisingly searched for msvcr100.dll and copied it to System32. Unfortunately, the search had found a 32-bit version, so as you can imagine, when File Meta was installed sometime later, it did not work at all. The rogue file had to be removed by hand to allow a correct installation to take place.

So please do check your systems to see if there are any possible problems in this area.

Dijji

[jmarkotic]

Just short comment - i installed 16.0.2. few days ago. Tagged 1-2 files, nothing bad happened (thoughi didn't practice any search on tags to provoke things). Yesterday I started tagging and then after some short timeout explorer got completely stuck for few mins. I had to wait to come out live again. I pasted logs, in that timeframe, though, I am not sure if anything useful is in there. p.s. Win10 was patched and somehow i hope this problem was resolved.

[jmarkotic]

C++ Runtime seems ok (I can see lot of MSVC++ libraries, but one from 2010 is x86 10.0.40219 is one from FileMeta (others are from 2013, 2015 both x64 and x86). So, I don't think it is problem there. After all FileMeta as app works fine.

[Dijji]

That sounds worrying. On your 64-bit machine, File Meta will not work properly without a 2010 64-bit C++ runtime. The Association Manager will not be affected, because it is not C++. Problems will not show up until you start using properties in Explorer.

When you are reporting what you have installed, are you talking about what you see in Settings/Apps, or what you find in the Windows directories? In particular, do you have the file "C:\Windows\System32\msvcr100.dll" on your system? If so, how big is it?

[jmarkotic]

attached is how it looks in control panel / installed apps:

Dll file is there: C:>dir C:\Windows\System32\msvcr100.dll 11.06.2011. 10:15 829.264 msvcr100.dll

Looks ok ?

[Dijji]

The date and size of the DLL are correct. The only thing that is odd is that there is no trace of how it got there. The control panel list in my development system looks like this: As you can see, I have a separate entry (in fact, more than one, because this is a development machine) for the x64 runtime. If you want to be completely sure that the version installed is good, rename the version in system32 (rename is usually better than delete because antivirus programs typically put the deletion straight back again) and reinstall File Meta. You should then see the appropriate installed entry.

[jmarkotic]

I deinstalled filemeta and renamed dll file, as suggested. After removing FileMeta, that version of VC++ Runtime (2010 x84 Redistributable 10.0.40219 was still there, not removed). When i reinstalled FileMEta (16.0.3) dll file is reinstalled (same size), but in terms of redistributable VC bundle, nothing new was added in control panel/installed apps. So in there I can still only se VC++ 2010 x86 version (along with many others, different years/versions). Shouldn't FileMta install redistributable bundle if required ?

Btw, when I add pdf handler, FileMeta can actually be removed and tag handler would still work ?

[Dijji]

Yes, I would have expected the redistributable to have appeared in the Control Panel, because that is what File Meta installs. It makes me wonder if you have an even more vigilant antivirus package than usual that picked up and reversed the rename. If you are curious, you might try renaming the DLL again, leaving it for a while, then coming back and seeing it if it has magically reappeared.

Another option: I will attach a zipped copy of the DLL to this thread so you can download it and compare it with the installed version using the command line and fc /b to do a binary comparison. If they match, I can stop worrying. msvcr100.zip As to your other question, if you uninstall File Meta you will no longer be able to access the properties of the PDF file. They will still be there in the alternate stream storage linked to the file, but nothing will know how to read them until you reinstall File Meta because the property handler will have been uninstalled.

[jmarkotic]

well, there os is some weirdness into all this. so, backup file that I did is still there (msvcr100.dll.back) and it is exactly the same as one you sent. on the other hand - file that was installed w latest 16.0.3 has different date 19.02.2011 and FC shows differences. And that one is active. Though, problem observed are pretty much the same.

Directory of C:\windows\system32 19.02.2011. 00:52 829.264 msvcr100.dll 11.06.2011. 10:15 829.264 msvcr100.dll.bac 2 File(s) 1.658.528 bytes 0 Dir(s) 120.282.406.912 bytes free

this is the one received in zip file

C:\windows\system32>dir C:\Users\jmarkotic\Downloads\msvcr100.dll

Directory of C:\Users\jmarkotic\Downloads 11.06.2011. 02:15 829.264 msvcr100.dll

C:\windows\system32>fc /B msvcr100.dll.bac C:\Users\jmarkotic\Downloads\msvcr100.dll Comparing files msvcr100.dll.bac and C:\USERS\JMARKOTIC\DOWNLOADS\MSVCR100.DLL FC: no differences encountered

with latest issues, explorer get stuck if I try to do something w pdf files that already have tag assigned or I am adding new tags to new pdf files (essentially, when handler is invoked). And now it no longer just restarts but get stuck for few minutes, after it recovers. I am ataching all logs after 16.0.3. installed. It is quite big. What is weird to me - i touched files inly in "Downloads" directory. Logs are full of files mentioned which I didn't deal with (and not sure what other programs might - mostly pdf files).

log_2020-05-22 - Copy.log

I really don't know how else to debug this further.

[Dijji]

I'm with you. I can't find a single error in that log file. By the way, the entries that you were not expecting are from the Index Service, working away in the background, indexing all the PDF files within its scope.

I will puzzle some more over this and over the DLL file versions tomorrow.

[Dijji]

I think I may have a sniff of the way to reproduce your problem. How many PDF documents do you have in your working folder? (Downloads in the last trace)

[jmarkotic]

total files 570 (mostly ppt, pdf, ...) , and out of those 240 pdf files.

[Dijji]

This is to give you an idea what I'm up to at the moment. No action requested from you.

I find the fact that the symptoms changed with version 1.6.0.3 significant. Nothing else I have done to date has affected the outcome at all.

Now, the area of change in that version was opening storages. Previous versions had focused on reading and writing values, which I considered much riskier. So it looks like the area to focus on is opening. And of course we have two separate processes opening storages: Explorer and the Indexing Server. So I have been looking for possible conflicts between the two. Hence the question about your folder: I wondered if the number of files that the two were looking at might change the balance of behaviour in a way to reproduce the problem. Unfortunately, not that easy.

So now I am working on a stress test tool that simulates the behaviour of Explorer and the Indexing Server as faithfully recorded in the logs, puts them on steroids, and then into a cage to fight it out. No results yet, but trying to destroy your own programs is always fun. I hope to get back to you soon.

Dijji

[jmarkotic]

Hi Dijji, I admire the effort you put in here. Some comments - fact is that on my laptop things stated to behave a bit differently recently (I think w 16.02.) - where explorer was no longer quickly crashed (and restarted soon), but now explorer goes into long "limbo" state (practically my whole desktop get stuck) and after 2-3min it recovers. But fact is that I patched my laptop just before that. even at some point i thought problem was resolved. What i can do is to try to replicate all this on Windows tablet (similar one - with all files synced mostly via OneDrive). PAtchlevel should be same as on laptop. I will get back.

[Dijji]

I have now completed work with my stress test tool designed to reproduce any possible conflicts between Explorer and the Indexing Server when reading properties.

The tool is called TestPropCollide, and the source is available as part of the File Meta repository. The program runs two threads. The Explorer thread reads each file in the folder, reads the Comments property from it, and updates the Comments every 20th file. The Indexer reads every property from each file in the folder.

Both iterate until the slower thread has read the requested number of files (the default is 10,000). Both threads run flat out: a run with 10,000 files might take around a minute.

The main measure produced by the tool is the collision rate, which is the percentage of the time either the simulated Explorer or the simulated Indexing Server failed to get the access they wanted to a file. Representative figures for the collision rates for different releases found in a series of tests are:

1.6 1.3% 1.6.0.3 2.6% 1.6.0.4 1.1%

As can be seen, 1.6.0.3 behaves considerably worse than the current recommended release. You can also see why there is now a release 1.6.0.4, which recovers the lost ground, plus a little more. Remarkably, it involved changing just three lines of code.

However, remember that this program deliberately pushes stress to the extremes: none of these figures should have caused any problems to manifest in day-to-day usage of File Meta. So the summary is, no smoking gun found to explain your issues, just more apparently solid behaviour.

All is good for the program however. The 1.6.0.4 property handler seems better in many ways than the one in 1.6, and will probably form the basis of the version in the next major release (without the logging, of course).

How is your replication going?

Dijji

[jmarkotic]

Hi, first - most important part. FM 1.6.0.3. running on MS Surface tablet with pdf handler and no issues detected whatsoever. I selected lot of pdf files and moved them into single directory and have been tagging, opening, moving around for at least 30mins. no problems (usually it happens in matter of few mins). On the other hand - on my main laptop, still issues. With FM and pdf handler active, I was working on directory with PPT files only (completely removed any pdf file from that directory), mostly tagging them. And I had issues 2x texplorer going frozen (stuck for few mins). This happened on much rarer occassion than usually (most likely due the fact there was not pdf file in working directory). After, removing pdf handler (FM still installed) - no issues whatsovever (was trying to reproduce it for 1 hr). So, at least in my case there is some weird interaction with FM/w pdf handler and maybe indexing service or AV or Onedrive sync service ... I might try to stop indexing service just to see if that is root cause in some way. Of course that 2 laptops can't be the same, but they are reasonably similar in setup. This is corporate pc and I have limited option of reinstalling, changing from the scratch. I can try for 1.6.0.4 but I don't think it would help here.

[fraxyz]

It looks that since 1.6.0.3 my crashes are gone. I dont know where exactly the problem was but I have experimented a lot with different pdf handlers. Now I use pdf-xchange for preview handler for pdf and none for properties handling except filemeta. Before when I had crashes I used adobe reader for both. Thank you very much for this great program :)

[amirlo91]

Hi, I installed "File Meta 1.6" and did as tutorial said in order to tag pdf files. After restarting the windows explorer, I right click on the file to go to the "properties" and saw the "tag" option. when click on it and wanted to type, the windows explorer stopped and closed that window. After that, whenever I wanted to right click on that file or later open the window, windows explorer stopped and close the window and cpu fan speeded very high and noisy. So I uninstalled it and restarted the win 10 but fan speed was high. After that I installed the "File Meta 1.6.0.4" and again the similar things happened. I would appreciate your kind support. Win 10 pro 21h2 (19044.1566)