The screenshot that I sent is when Workshelf was 100% unresponsive. NextStart was still working just fine like always. Right now I am having to use my desktop for creating backup externals for a customer but maybe it won't be too late and I can attempt the test again and get you everything you need. If not then I will definitely be doing it tomorrow night.

And yet... 0% CPU usage. Let me tell you upfront, none of this makes much sense lol
Something is making WorkShelf 'block'.

Have you heard about SysInternal's (now acquired by Microsoft) Process Explorer? You can download it from HERE if you want.

It allows you to take a 'snapshot' of a processe's stack (double click on the process name, select the Threads tab, select the top main thread, click the Stack button). Sometimes this is enough to give us a clue as to what is happening internally.

There is also Process Monitor by the same guy(s) - it allows you to monitor all IO that a given process is currently performing, for instance.

But, of course, this is all very technical.

0x0000000000000000
ntdll.dll!NtAlpcSendWaitReceivePort+0x14
wow64.dll!Wow64LogPrint+0xfdf
wow64.dll!Wow64SystemServiceEx+0x153
wow64cpu.dll!TurboDispatchJumpAddressEnd+0xb
wow64cpu.dll!BTCpuSimulate+0x9
wow64.dll!Wow64LdrpInitialize+0x26a
wow64.dll!Wow64LdrpInitialize+0x127
ntdll.dll!LdrInitShimEngineDynamic+0x3133
ntdll.dll!memset+0x1ee3d
ntdll.dll!LdrInitializeThunk+0x63
ntdll.dll!LdrInitializeThunk+0xe
0x0000000000000000
This is the stack when everything is working directly after a reboot

Also I don't know if it matters but I have 11 subdocks and all of them have custom icons. My dock also have the task bar at the end and still has the Shutdown and Restart "modules".

Here is a screenshot of Taskmanager and SysInternals while it is working.

Ok, thing is, normally the contents of the stack are changing hundreds of thousands of times per second. When you press the Stack button, you take a 'snapshot' of that process at a particular moment in time. Press it again and what you see is completely different.

When a program is frozen because it is being blocked by something external, however, chances are the stack contents will be 'frozen' too. Or, if a process is completely hammering the CPU because it's calling the same routine thousands of times a second, then the chances of capturing a snapshot of whatever is actually hogging the CPU increase exponentially (but sometimes you have to press the Stacks button several times to figure out what 'repeats'). These are the cases when the Stack button is useful.

It has started to get really laggy and I noticed WMIC.exe activating in sysinternals. I have attached a screenshot.
This is after clicking on a subdock on my main dock. And the subdock won't go back on its own I have to click the icon again to deactivate it.

Might it be a good idea to have a bunch of monitoring tools on my screen and create a video of it? Then I could upload that so you could see it and watch whatever is happening.

And now it is frozen and unresponsive.

Does not matter... The important thing was not to run ANY of the modules that appear in the Modules tab of WorkShelf Preferences (which includes the Recycler module).

Do this and see if WorkShelf keeps freezing, and let me know. If it does, let's try running it without ANY sounds: open Preferences, go to the Sounds tab and disable both sounds and voices.

Also, I take it you're not using the built-in Media Player to listen to music, or are you?

That was quick. Are you sure you have no modules anywhere? Not even in the sub-docks?

Ok, hold on.

I saw ZA (Zone Alarm) in the screenshot and that rang a bell. So I searched the Winstep support email database and I found a reference to issues between the two:

"2019-06-28

Info Update...

I have another Windows 10 x64 PC that uses Winstep Nexus and ZA FW,
Windows has been updated to v. 1903,
The exact same situation is happening,
ZA FW at 15% CPU and Nexus unresponsive !

There is something related to this Windows update that is causing this odd behaviour between ZA FW and Winstep products..."

So, my guess is that ZA is causing the problem. Check out ZA FW CPU usage in Task Manager when WorkShelf is frozen. Try temporarily uninstalling ZA to see what happens.

With workshelf unresponsive I shut down ZA and after 14 seconds everything was back to working again. I guess I will play around with ZA and see if I can figure out what might be killing workshelf and not nextstart.
Thank you all for your help and I will be sure to reply back if I find a fix.
I have never ran into an issue where ZA basically froze an application.

I think this is a combination of Windows 10 build 1903, ZA and WorkShelf. You should probably post about this in the ZA forums (the user I quoted above did) so they become more aware that ZA is now interfering with the normal functioning of other applications.

As you can see, without ZA there are no issues with WorkShelf. Therefore this is something Checkpoint needs to fix, although, personally, I blame Microsoft for their constant changes to the OS without adequate QA testing.

I am right there with you about blaming Microsoft. They just need to give up and go to Linux...lol.
I am currently talking with a ZA rep about this.
I will update with what I find out from them.

UPDATE FROM ZA: According to Nick A. with ZA 1903 has been causing their customers some serious problems, especially with 3rd party applications. They are trying to figure out where the issue stems from but have not been able to find it as of yet. Nick escalated my issue and gave me a ticket number and as I find things out I will keep yall updated as well.