PDFShellTools under limited account

[hhcc]

PDFShellTools causes xplorer2 crash under limited user account: xplorer2 works fine unless it opens a directory containing pdf's and the "Details" view has columns.In that case, xplorer2 works fine until it is closed when it crashes. I confirmed it is PDFShellTools' fault by installing PDF-Xchange, which takes over the shell extensions (although it does not have the same functionality as PDF-Xchange), and xplorer2 does not crash in that case (it takes some time to show the icons though).

In another problem related to PDFShellTools, it causes OneNote to lose search registration and prevents (under limited acounts) its re-registration. See the error messages produced by OneNote:



Any ideas about a possible solution?

[RTT]

PDFShellTools causes xplorer2 crash under limited user account:

Windows user limited account? And works fine with administrator accounts?
With what Windows and xplorer2 versions
Have you checked with other Windows Explorer alike tools (UltraExplorer, Total Commander,...)?

In another problem related to PDFShellTools, it causes OneNote to lose search registration

And what service is OneNote trying to register? A Property Handler for OneNote file types? If yes, then unless it register also for .pdf files (and in this case only one property handler can be registered for each file type), I can't see where PDF-ShellTools can be responsible. Do you know what registry keys the OneNote changes?

and prevents (under limited accounts) its re-registration.

That probably because under limited account OneNote setup can't make changes to the registry.

[hhcc]

I am using Windows 7 Ultimate 64 bits.

PDFShellTools causes xplorer2 crash under limited user account:

Windows user limited account? And works fine with administrator accounts?
With what Windows and xplorer2 versions
Have you checked with other Windows Explorer alike tools (UltraExplorer, Total Commander,...)?

Yes, PDFShellTools causes the crash under limited accounts only. There is no problem under administrative accounts.

I have checked explorer++, but that does not seem to use shell extensions, so I ditched it. I have not tried UltraExplorer not TotalCommander. I will if I cannot solve this issue. I want to be able to save column settings on a per-folder basis.

I am using the xplorer2 version 1.8.1.2 [Unicode] x64 1/25/2011.

In another problem related to PDFShellTools, it causes OneNote to lose search registration

And what service is OneNote trying to register? A Property Handler for OneNote file types? If yes, then unless it register also for .pdf files (and in this case only one property handler can be registered for each file type), I can't see where PDF-ShellTools can be responsible. Do you know what registry keys the OneNote changes?

and prevents (under limited accounts) its re-registration.

I spent 4 hours with Microsoft technical service trying to fix this issue. At the end, I had to grant temporarily administrative permissions to my limited account. Anyway, I can reproduce the steps that lead to that OneNote issue. Any change in the property handler using PDF-ShellTools Manager will cause OneNote to "unregister" from the search service.

I have tried re-installing PDF-ShellTools, un-installing Acrobat reader, re-installing Acroba professional, uninstalling "Fixes for 64-bit Adobe Reader", etc.

[hhcc]

Update:

The OneNote issue is not unique to PDFShellTools. It also happens when I install/remove Acrobat's PDF IFilter for 64.

[RTT]

I've just now tested the xplorer2 under a Windows 7 user limited account and I can confirm the issue. Program crash at close if during the session a folder with PDFs, and in details view, invoke the PDF-ShellTools Property Handler.
No issues with Windows Explorer and UltraExplorer, so I suppose it's a problem with xplorer2 itself. Could be related to something that the PDF-ShellTools is not doing correctly, but most probably involves a valid situation (the other explorers don't crash) not correctly handled by the xplorer2. You should contact the developer to see if he can fix the problem.

[hhcc]

The 32 version of xplorer2 does not crash with PDFShellTools, only the 64 version does. That will work for me for the time being.

Thank you for your prompt response,

A happy customer.

[hhcc]

It is PDFShellTools's after all.

I use w7x64 but PDFShellTools installs in "Program Files(x86)" instead of "Program Files". The default value of

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\PropertySystem\PropertySchema\0002

points to

%ProgramFiles%\PDF-ShellTools\PDFShellTools.propdesc

but that file obviously does not exist. Windows Search Service (WSS) tries to index meta-data using that schema that cannot find. Since WSS breaks, OneNote tries to repair it. It does so by disabling PDFShellTools column handling (reverting to a existing schema).

The solution:

I copied the folder from "Program Files(x86)" to "Program Files" and I let OneNote repair WSS. OneNote and PDFShellTools work together now.

[RTT]

That registry key is created by the Windows API itself, function RegisterPropertySchema from the IPropertySystem Interface, when registering the property schema. The use of that environment variable "%ProgramFiles%" for the property description schema path seems to be wrong, because such variable maps differently if expanded by a 32-bit or 64-bit application. I have no idea why the API uses an environment variable for that, and not the passed plain path (probably a bug?).
PDF-ShellTools call the RegisterPropertySchema function from a 32-bit application. Interestingly, if called from a 64-bit one, that key changes to "%ProgramFiles% (x86)\PDF-ShellTools\PDFShellTools.propdesc", which is also wrong if expanded by a 32-bit application, that will get "C:\Program Files (x86) (x86)\PDF-ShellTools\PDFShellTools.propdesc"

I haven't read any info, in the property system documentation, about the need to have the property schema file duplicated to make it accessible by 64 and 32 bit applications/shell extensions. Do have any info about that?

Another question that remains is why that OneNote privilege elevation tool (ONELEV.EXE) is reading that key anyway. It is using an API function for that (and what), or is reading it directly (and if yes, it is a wrong method)?
I ask this because the property schema seems to be correctly registered this way, with both 32-bit and 64-bit applications able to enumerate/access theses PDF-ShellTools custom properties.

What happen with OneNote if you remove that copy of the PDF-ShellTools folder from the "C:\Program Files\", and change that registry key to "C:\Program Files (x86)\PDF-ShellTools\PDFShellTools.propdesc" ?

[hhcc]

I have no idea why the API uses an environment variable for that, and not the passed plain path (probably a bug?).

Feature you mean 

I haven't read any info, in the property system documentation, about the need to have the property schema file duplicated to make it accessible by 64 and 32 bit applications/shell extensions. Do have any info about that?

Nope

Another question that remains is why that OneNote privilege elevation tool (ONELEV.EXE) is reading that key anyway. It is using an API function for that (and what), or is reading it directly (and if yes, it is a wrong method)?
I ask this because the property schema seems to be correctly registered this way, with both 32-bit and 64-bit applications able to enumerate/access theses PDF-ShellTools custom properties.

It has to do with the indexing service. I guess OneNote uses it to extract metadata from pdf files embedded in its own ".one" files.

What do you mean by "this way"? When I check Control Panel->Indexing Options->Advanced->File Types->.pdf, I get "Registered IFilter is not found". I know that the property schema is not the same thing as the IFilter, but I understand that they are both related to column handling.

Before installing PDFShellTools, I had installed "PDF fixes for 64 bits" and "Adobe PDF iFilter 9 for 64-bit platforms". This last one was supposed to give me the option of searching inside pdfs (I am using Copernic now) and be useful with Adobe's column handler.

What happen with OneNote if you remove that copy of the PDF-ShellTools folder from the "C:\Program Files\", and change that registry key to "C:\Program Files (x86)\PDF-ShellTools\PDFShellTools.propdesc" ?

I'll try it in a couple of weeks, so far I got it working with the extra copy. Anyway, I have so many programs dealing with pdf's that it would be difficult to pin to the

[RTT]

It has to do with the indexing service. I guess OneNote uses it to extract metadata from pdf files embedded in its own ".one" files.

Probably, but I don't see why the OneNote has to use a different method than the provided by the Windows API itself, that, if used, is able to correctly interface the PDF-ShellTools property handler, from both 32 and 64 bit processes.

What do you mean by "this way"?

With that "%ProgramFiles%\..." path.

When I check Control Panel->Indexing Options->Advanced->File Types->.pdf, I get "Registered IFilter is not found".

I don't have any IFilter for PDF's installed, and the filter description I get there is "File Properties Filter"

I know that the property schema is not the same thing as the IFilter, but I understand that they are both related to column handling.

Both the property handlers and IFilters can provide access to properties and full text content, and a registered property is not necessarily registered as column. Can be used by the Windows Search, but not show as Column.
You can get extended info here:
http://msdn.microsoft.com/en-us/library/aa965717(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/bb266532(v=vs.85).aspx

[hhcc]

What happen with OneNote if you remove that copy of the PDF-ShellTools folder from the "C:\Program Files\", and change that registry key to "C:\Program Files (x86)\PDF-ShellTools\PDFShellTools.propdesc" ?

I tried it this way and OneNote works fine, xplorer2 still crashes at exit.

[RTT]

I tried it this way and OneNote works fine

Thanks for confirming it.

xplorer2 still crashes at exit.

For sure not related to this issue. I don't see xplorer2 enumerating these keys directly as the OneNote seems to be doing.