After a fresh reboot you start PM and it runs normally.
You close PM, pmotion.exe quits completely.
You start PM, pmotion.exe is running but you don’t see anything.
Goto 1
Is that it?
If you are at point “3”, do you see the application entry in your taskbar, so that it also looks like running at the taskbar and you can switch from and to it, but only the windows don’t show?
What do you see if you hit Alt + Tab. Does it show anything from Pro Motion there?
Correct on points 1, 2 + 3. And yes, it’s in the task manager running, and there’s no window that displays, ever, not even the splash screen loader. I actually have a .dmp file from attaching to the debugger, pausing, and saving the process if you want it. I just don’t want to post that publicly (since it might contain a loaded license file in memory or other private information).
Just to clarify the scenario, the promotion process would never load, it wouldn’t bring up a splash window, as if the program was paused in the background without ever bringing up a screen and it wasn’t because there was a previous promotion process running that had not quit.
Something interesting happened. I had a separate programmed called VS Code running which promoted to update itself. I accepted the update from VS Code, and the moment VS Code respawned, a previously stalled promotion process started to display its splash screen and continued loading as normal. Ever since the VS code upgrade occurred, promotion has been running fine. I have no explanation and I can no longer reproduce the original issue.
That’s interesting, and it resembles my original problem with the OCR application that was blocking PMNG.
Did you use VSCode to edit some PM configuration files? That might have created an handle on the config file that was preventing PM from accessing it in write mode — this was a typical issue on Windows XP, when some apps would create persistent handles on files, which wouldn’t allow deleting them or renaming them, and required closing File Explorer in order to delete them. Although this is not so much of an issue on modern Windows (7, 8, 10) it can still happen, especially with apps that store settings inside the installation folder (as PMNG does) instead of the user folders.
Next time that PMNG hangs, you should try to close File Explorer via the task manager, and see if it can successfully launch — if it does, then it’s a file handle that’s causing the problem. Of course, you’ll need an alternative file explorer to carry out file operations once File Explore is closed. You can download this (excellent) free tool:
(I’ve used Altap Salamander as an alternative to Explorer for years, since before it became a free tool)
The only other thing that comes to my mind, regarding VSCode blocking PMNG, can be the printer drivers, which they probably share. Scanner and printers drivers are often the cause of similar conflicts, and the vanilla Windows installation contains tons of preinstalled drivers, even if you don’t use them. Disabling or uninstalling them might be a step worth looking into — in any case, they will be automatically re-installed if a device needs them, and might even be replaced by a better/newer version, so it’s a safe operation to do (unless you’ve installed the custom drivers that ship with the hardware; but even then, it might solve some underlying problems).
No, they were just running independently and I had not edited any PMNG configuration file.
I can’t reproduce anymore but it if it happens again I’ll check the steps recommend. As for printer drivers, it’s a fresh machine installation and I only added my main printer (which was a default win 10 driver only). So maybe, but doubtful.
I just has this issue on Windows 11 22H2 (see this forum post). Seems if VSCode is open and wants to do an update when it closes, it blocks PM-NG from starting. I can run VSCode without it wanting to do an update and PM-NG opens fine, it’s just when VSCode wants to update that it blocks PM-NG.
Could now make it happen with a running VSCode where there was a pending update for.
PM checks if there is already another instance of PM running and this check interfered with the update application of VSCode because it uses that same name for its application window. That’s why some check message was sent to that window but weirdly this message was not processed and not ignored either, it was not answered and so the process waited forever.