I have two thoughts on this:
Some EFIs are highly sensitive to filesystem damage, which might make it look as if a new GRUB binary was improperly signed. This would then trigger the MokManager display you've shown. (It's not technically Shim that's showing that display, but MokManager.) In this case, you may be able to fix the problem by doing:
sudo dosfsck /dev/sda2
You'll need to do that from an Ubuntu emergency disk, of course. Also, this type of damage can occur if you failed to both disable Fast Startup and disable hibernation. Thus, it's important that you disable these Windows features to prevent a recurrence.
Note also that if the filesystem is damaged, you might need to re-install GRUB -- but do so after fixing the filesystem problem. Boot Repair should be able to help with this.
A new bug
It could be there's been a recent update to Shim and/or GRUB that's causing it to flake out on your particular computer. In this case, reverting to the old version may help. This may require copying the
shimx64.efi binary from another computer or re-installing GRUB in some way. Alternatively, if the bug is in GRUB, you could install another boot manager entirely. I describe several on this page. I haven't noticed any recent updates to either Shim or GRUB, but I may have missed something.
With Secure Boot off, you can bypass Shim entirely by creating a new boot entry with a command like this:
sudo efibootmgr -c -d /dev/sda -p 2 -l \\EFI\\ubuntu\\grubx64.efi -L GRUB
This command tells the computer to boot via
grubx64.efi on partition 2 (
-p 2) of
-d /dev/sda). Your current setup boots via Shim, which is necessary to handle Secure Boot; but with that feature disabled, a direct call to GRUB can bypass any Secure Boot flakiness -- assuming there's nothing wrong with the GRUB binary. As noted earlier, if that binary is damaged, it could create the symptoms you're seeing, and this procedure would not help -- the system would simply fail to boot in some other way.