Closed whulkhulk closed 1 year ago
The dll file doesn't get registered/applied and also it can be deleted!
It might fail to register the DLL. (If it was registered to Windows Explorer, you cannot delete the DLL.) It works well on my PC. (Windows 10 22H2 19045.2728) It should work on old Windows OS, too. You see which step it fail by Resistry Editor.
It creates key:
HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{333EFDA5-A74E-4df4-A225-92A7AF81F29A}
It creates key:
HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{333EFDA5-A74E-4df4-A225-92A7AF81F29A}\InprocServer32
It sets default value: full path of the DLL (something\MultiParShlExt64.dll)
It sets ThreadingModel
value with Apartment
.
It creates key:
HKEY_CURRENT_USER\SOFTWARE\Classes\*\shellex\ContextMenuHandlers\MultiPar Shell Extension
It sets default value to {333EFDA5-A74E-4df4-A225-92A7AF81F29A}
.
It creates key:
HKEY_CURRENT_USER\SOFTWARE\Classes\Directory\shellex\ContextMenuHandlers\MultiPar Shell Extension
It sets default value to {333EFDA5-A74E-4df4-A225-92A7AF81F29A}
.
(If possible) It tries to set value {333EFDA5-A74E-4df4-A225-92A7AF81F29A}
in:
HKEY_CURRENT_USER\SOFTWARE\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Approved
Please check these Resistry keys and values. If it stoped in the middle of the steps, something error happens at that time.
If they are set correctly, Windows OS may block the DLL. Please check your the following OS setting. Allow only per user or approved shell extensions
All keys has been created successfully expect the last one which is: HKEY_CURRENT_USER\SOFTWARE\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Approved
But I have added it to this one but still not working: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Approved
What message-box is shown, when you type regsvr32.exe MultiParShlExt64.dll
on Command Prompt ? It should say "DllRegisterServer in MultiParShlExt64.dll succeeded.", if it set values correctly. You can un-register DLL by typing regsvr32.exe /u MultiParShlExt64.dll
. It should erase all registry keys/values which it registered ago, if it did clean-up registry.
If you get a error, you may need administrator account or privilege temporary. I found some incidents on the Internet.
You receive 0x80070005 error when you try to register a DLL by using Regsvr32.exe
DllRegisterServer failed error code 0x80040201 schmmgmt.dll
How is installed directory of MultiPar ? The length of full path (include DLL filename) must be less than 260 characters. Also, Shell Extension DLL MultiParShlExt64.dll
must exist in the same directory of MultiPar.exe
. If you change directory after register DLL, you need to register again to update path.
Do you use other Shell Extension DLLs ? There may be conflict. If another DLL consumes space of entries, other DLLs may not work. It depends on the order of loading DLLs. In this case, unregister another DLL may help.
MultiPar is installed on the root of the hard drive partition "D:\MultiPar" It shows a succeeded message with both register and unregister the MultiParShlExt64.dll using regsvr32.exe Tried to launch it using Admin ( my UAC is disabled though ) also unregistered any DLL in the context menu but still not working..
So, there seems to be no problem in register. It may fail to add item on the context menu. Did you try restart Windows Explorer after regiser DLL ? On old PC, I logout & login Windows OS again to update Explorer settings ago.
You may try simple menu by adding a new line on MultiPar.ini
.
[Option]
ShellExtension=56
This options (8, 16, 32) will omit icon and reduce entries. When you changed behavior, you need to restart Windows Explorer to update. If something error happens in those feature, it may work without them.
When all of them don't help, I can make a debug version to save running steps. Then, I will be able to see which step it did or could not. It depends on how eager you want to test.
Tried that and still not working.. Sure will wait for the debug version to test it.
I made debug version DLL. I put the package (ShlExt_sample_2023-03-19.zip) in "MultiPar_sample" folder on OneDrive. Though I'm not sure it works, it's worth to try.
Thanks for the file, tried it but still not working also there is no "debug.txt" file after registering MultiParShlExt64.dll using regsvr32.exe
I found an interesting point, when I saw debug output from Shell Extension DLL. It returns short file name (8.3 format) for very long path (exceed 260 characters). Normally, Windows OS stores short filename (8.3 format), too. But, someone may disable the feature for SSD. How is your setting of drive ? If the path length is the problem, it may work for short filename. (Or it may work, when full path length is not so long.) Did you test Shell Extension behavior with short filename ?
I made debug version DLL to save selected file's path. I put the new package (ShlExt_sample_2023-03-20.zip) in "MultiPar_sample" folder on OneDrive. If it doesn't make "debug.txt" still, it fails former than checking file path.
Still the same issue with no "debug.txt" file. The path is very short "D:\MultiPar\MultiParShlExt64.dll" so I don't think it's causing this issue, also tried to rename it to "MP64.dll"
I found an article on the internet.
If there is CLSID {333EFDA5-A74E-4df4-A225-92A7AF81F29A}
under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Shell Extensions\Blocked
,
MultiPar's Shell Extension DLL isn't loaded. Please check the entry.
Only "Approved" and "Cached": HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Shell Extensions\Approved HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Shell Extensions\Cached Also {333EFDA5-A74E-4df4-A225-92A7AF81F29A} is in the "Approved" key.
Oh, I see. Then, it should be loaded. So, I felt that it happened to be unloaded before running. I slightly changed my source code after reading other samples. I made debug version DLL to save more information. I put the new package (ShlExt_sample_2023-03-20b.zip) in "MultiPar_sample" folder on OneDrive. If it doesn't make "debug.txt" still, it fails to call DLL somehow.
Unfortunately still the same with no "debug.txt" file.. Also the weird thing that is shows that "MultiParShlExt64.dll" registered successfully but still can be deleted without un-registering it.
While Windows Explorer is loading a DLL, you cannot delete the DLL. If you can delete a DLL, it means that the DLL isn't loaded yet. When regsvr32 command writes registry entries, the target DLL isn't loaded yet. Windows Explorer reads the registry for your selected file type. In this case, MultiPar Shell Extension is set for *
(all files) and Directory
(all folders). Then, Windows Explorer loads the registered DLL, when you right-click a file.
Now, problem is that Windows Explorer doesn't load the DLL on your PC. Does your using Windows Explorer 64-bit ? There are both 32-bit and 64-bit Windows Explorer on 64-bit Windows OS. If you use 32-bit application, it doesn't load 64-bit DLL. (However most users don't use 32-bit Explorer on 64-bit OS.) You may see which version is running on Task Manager.
It may be blocked by per user setting. On Registry Editor, HKEY_LOCAL_MACHINE
is for all users, and HKEY_CURRENT_USER
is for current user. Even when the DLL isn't blocked for all users, it may not for a user. Please check it.
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Shell Extensions\Blocked
I'm using the 64-bit version, also "Blocked" key doesn't exists for both registries "HKEY_LOCAL_MACHINE" and "HKEY_CURRENT_USER". I really don't know what's causing this issue for "MultiParShlExt64.dll", all other Shell-Extensions works without issue..
all other Shell-Extensions works without issue.
Then, their difference may cause this problem. MultiPar Shell Extension is different from most others. It saves data under HKEY_CURRENT_USER
, while others save data under HKEY_LOCAL_MACHINE
. I made a sample to use HKEY_LOCAL_MACHINE
. It will be worth to try.
I put the new package (ShlExt_sample_2023-03-23.zip) in "MultiPar_sample" folder on OneDrive. You need administer privileges to register. I used Run as administer
option to open Command Prompt, when I tested the DLL.
That's impressive, it works now finally! Thank you for your time and efforts finding and fixing what causing this issue.
If it finally fixed would be great! It didn't worked for me before, I wrote once.
Tried and it's work's for me too. Would be cool to using new context menu Windows 11, but anyway nice that it working now.
whulkhulk That's impressive, it works now finally!
Slava46 It didn't worked for me before, I wrote once.
Oh, I see. Thank you for test sometimes. Windows Explorer seems to change behavior (which DLLs to load) by user's privileges.
For compatibility with other users, I made a function to check privileges. Only when a user has administrator privileges and UAC (User Account Control) is disabled, DLL registers data under HKEY_LOCAL_MACHINE, instead of HKEY_CURRENT_USER. So, it works samely (write/read HKEY_CURRENT_USER) for most users. Even whan they register DLL by "Run as admin under UAC enabled", it uses HKEY_CURRENT_USER. But, it will write/read HKEY_LOCAL_MACHINE for you, because you disable UAC.
I put the updated package (ShlExt_sample_2023-03-23b.zip) in "MultiPar_sample" folder on OneDrive. It doesn't write debug output on file "debug.txt", as it did run properly. If it works well, I will release the new DLL at next version. Please test it.
ShlExt_sample_2023-03-23b.zip this one seems working too like previous.
Yes, this version works too.
I see that in "ReadMe" you reduced the number of using command values in preparing for the new release. So if possible, can you make an option to use only one menu "MultiPar" ( without any sub-menu ) in the context menu to launch MultiPar instead of clicking on "MultiPar->sub-menu" ?
Thank you for checking the behavior. I spent long time to fix this bug, hehe.
So if possible, can you make an option to use only one menu "MultiPar" ( without any sub-menu ) in the context menu to launch MultiPar instead of clicking on "MultiPar->sub-menu" ?
Users can change items on menu. Add below line under [Option]
in MultiPar.ini
file.
ShellExtension=64
For me with ShellExtension=64 still sub-menu is. Restarted explorer.exe and re-registered MultiParShlExt.dll.
Anyway for Windows 11 made with Custom Context Menu in main menu without sub-menu, it's much faster now for start.
For me with ShellExtension=64 still sub-menu is.
Does the DLL read MultiPar.ini
correctly ? Normally, MultiPar.ini
exists in the same directory as DLL.
I made sample to write path on "debug.txt".
In the debug output, there will be a line like;
MultiPar.ini path = full path of MultiPar.ini
If the path is different from real file location, something is wrong. If it read option ShellExtension=64
correctly, next line will be menu_behavior = 120
. (8 + 16 + 32 + 64 = 120) I put the debug version (ShlExt_sample_2023-03-23c.zip) in "MultiPar_sample" folder on OneDrive.
I don't know how context menu will be on Windows 11.
Ok, single menu works now by using ShellExtension=64 but there is no icon in the menu.
MultiPar.ini
[Option] ShellExtension=64
MultiParShlExt.ini
MenuTitle=&MultiPar Comment=English [0x0409] MenuTitle=&MultiPar
but there is no icon in the menu.
Oh, I happened to disable icon, too. New sample will disable sub-menus only. I put the new package (ShlExt_sample_2023-03-24.zip) in "MultiPar_sample" folder on OneDrive. I'm sorry for bothering you.
All works well now 👍 Thanks a lot :)
Since it's now fully working, Can you make MultiPar context menu visible when clicking on background folder? ( to add files and folders from the same path when running it from context menu )
Can you make MultiPar context menu visible when clicking on background folder?
I'm not sure what you want to do. When you click "background folder", you don't select any files. Then, MultiPar doesn't know which file to open. Sample picture of example usage will be helpful.
When you click "background folder", you don't select any files. Then, MultiPar doesn't know which file to open.
MultiPar can use the same background folder path and add all files/folders in that folder.
There is a tool called "FileMenu Tools" that can calculate size of folders when start it from"background folder" using context-menu.
If you want to select all files in a folder, you just select the parent folder. When you send path of a folder to MultiPar, it will search all files in the folder. You can select a folder and send to MultiPar by using context menu or SendTo
. I don't want to add a new feature, when there is another way of same usage already.
Intergate Multipar into Shell doesn't work..
Used the MutltiPar GUI or even the manually command "RegSvr32.exe MultiParShlExt64.dll" The dll file doesn't get registered/applied and also it can be deleted!
It dosn't show error or anythings when trying to register/intergate it...
Windows 10 x64 21H2 build 19044.1288 with Windows Feature Experience Pack 120.2212.3920.0
Edit: UAC is also disabled.