I have updated our PDM test server from 2023 SP5 to 2024 SP5 using our backups.
The machine is a clean windows server setup wiped and installed from scratch, only the vault was updated from our current 2023 backups.
When I double click our tasks inside PDM administration tool, a message I have never seen in the past comes out and after pressing OK the normal TASK dialog with the task settings came out: “Hash argument must have some string.”
What does it is supposed to mean?
Updated the Print and convert tasks (that we do not use) and double clicking on them makes this dialog come out too.
Dialog aside pdm seems to work normally.
SW devs: please put a bit on effort into your UI design, even for dialogs we arenot supposed to see a small hint about what caused it.I understand that it should be some sort of integrity check on something… well the something part is my concern at the moment.
Is this a Solidworks PDM Add-in or third party? Sounds like it could maybe be fired from the add-in that may need to be updated for 2024.
I have the sw2024 addin and I need to check if I mistakenly used another version for the upgrade.
Otherwise I am clueless.
That addin should be already the 2024 version unless our VAR (or me) messed up the files since their addin properties are stuck at 2020 or so…it is difficult to understand if the upgrade is ok or not. 
Worth trying again deleting the current addin and adding the dlls again. But the question is: why the dialog shows within tasks??
If I understand correctly, you’re talking about editing the Task through the Admin Tool. There’s a couple events fired when the task settings dialog is open or closed, which the add-in must add hooks to. My hunch is that something in that add-in code is presenting the nameless warning/error dialog.
//Register to call OnCmd on task-related events
poCmdMgr.AddHook(EdmCmdType.EdmCmd_TaskSetup);
poCmdMgr.AddHook(EdmCmdType.EdmCmd_TaskSetupButton);
From PDM API Help Example
3 Likes
Ok today, I am going to take another look at the issue. No answer from SW yet, my VAR asked them and waiting for a reply.
checked again and @bnemec nailed it.
To update a third party addin dll I installed it on our pdm windows server which has also a pdm client installed on it.
The add in installer did not check the OS and let me do it (it was just to unpack the addin dlls).
I forgot to uninstall the addin from the server and it apparently caused this issue.
2 Likes
Related?
[3DSwym](https://SWYM thread on similar error.)
The dialog was caused by the addin license validation that used an hashed SW serial for the purpose.
Since the PDM server has not need of a SW copy installed there was no serial in the registry, triggering the error dialog.
nice the technical support from the maker was not aware of it.
1 Like
Nice. I’m curious how you wound up getting to the bottom of that mystery.
You said that’s an add-in your VAR created?
Devs sent me a copy of the addin that would trigger a LOG creation upon loading the addin in solidworks. In the log “salt hashing” was mentioned after serial number reading so it was likely what the error message was about.
I confirmed it with Sysinternals process monitor, filtering the path including “solidworks” keyword I noticed that during the dll initialization it was scraping the registry trying to find solidworks keys, it was basically looking for our serial number.
Dumped SW REG subkey from my workstation and put it into the server (serials from HKLM was enough iirc).
I was having a nice discussion with @JimSculley via private message about another issue we had with this addin on some machines and he helped me finding the solution for that too.
He mentioned dnspy to look at the dll source code to understand what the addin was doing and it pointed me in the right direction: devs were assuming the remains of old SW install in the registry would be intact, without missing or corrupted values and were trying to read a missing data that returned a null value somewhere.
Since I deploy the local installation of SW and its addins with BAT scripts, I added a routine to look for the past SW keys in the registry and deleted them all. Problem solved.
It took 5 days and my test machines were all clean install so no old SW registry and no problem during the test phase.
