Cannot load 32bit plugin even when 64bit versions of all are installed
-
Ah.
Ok, so I tried creating a zero-length (intentionally “corrupt” dll) file:
...\plugins\ComparePlus\ComparePlus.dllAnd I got the same error message you received:
This is somewhat surprising (the error message being “… 32-bit …”), leading one down the wrong path…
So, my new advice might be to look at possible corruption in the copied files.
-
@Alan-Kilborn the SHA-256 hashes of the files match which to me would indicate the issue isn’t with corrupt DLLs however it is good to know that corrupt DLLs could cause the issue.
-
I think quite possibly the “…32-bit…” error message might occur for ANY failure in loading the plugin DLL. So, even if the files are not corrupt, I suppose there could be permissions issues or other problems relating to the file system…?
EDIT: Ok, I’d be wrong in that. :-) HERE’s the code that loads a plugin. And HERE’s where it sets your error message.
-
@Alan-Kilborn thank you, you seem to have hit the nail on the head, the subfolders created by the script are not correctly inheriting permissions from “C:\Program Files” and therefore <devicename>\Users didn’t have permission to execute the DLL, just modifying the script now to force inheritance on those folders and will update shortly once I have pushed a test deploy
-
I can confirm that the issue was indeed with the permissions on the plugin folders, this was traced back to the robocopy command we were using being incorrect, thank you very much for all your help in this
Daryl
-
Well, if you’re still around, if you had any more detail about exactly what was wrong, it might help drive a change to Notepad++ code to provide a more helpful error message if others encounter the same problem in the future.
-
@Alan-Kilborn certainly, always happy to contribute where I can
the issue was caused by my malformed robocopy command which stripped execute permissions from the DLL, as you said above, notepad++ throws a “cannot use 32bit plugin” error any time it can’t access the DLL, so even though it was receiving a permissions failure, it was taking this as a malformed DLL and spitting out the erroneous error. when the error in the robocopy was rectified the issue disappeared. my solution would be to look at building a better error catch system that catches specific file errors and parses them into more appropriate error messages, perhaps:
Missing DLL
Permissions
Corrupt DLL
Wrong architecture DLLalthough the technical implementation side of this is not something I would be able to help with much as c++ is not a language I have much experience with
-
@Daryl-Titcomb said:
Missing DLL
Permissions
Corrupt DLL
Wrong architecture DLLYes, that’s where I was going as well…
@Daryl-Titcomb said:
although the technical implementation side of this is not something I would be able to help with
That’s fine, I was really just looking for the root of your problem, which you provided, so thank you.
From here, we can turn it over to the dev team for consideration.
-
I created an official N++ issue, HERE.
-
The misleading error message was resolved, see HERE; however the improvement request for more specific error messages remains incomplete as of now.
-
P PeterJones referenced this topic on
-
