System freezes immediately on suspending, where do I investigate?

I've just tried to suspend to RAM (i.e. sleep) my newly installed Xubuntu 19.10 machine, a Lenovo S340 Ideapad with a replaced SSD. Upon pressing suspend while logged in, the system freezes instantly. The screen does not go black and even after half an hour, the machine accepts no inputs other than the classic REISUB combo. I can't even move the mouse or change tty. This happens whenever I attempt to suspend, even with systemctl suspend and xfce4-session-logout --suspend. Strangest of all, this does not occur on the same OS's Live Disk.

Where can I investigate the cause of this problem? kern.log shows the entry PM: suspend entry (deep) at what looks like the appropriate time, but nothing comes before this other than what I was doing many minutes before and nothing comes after until the reboot has started. On the other hand, syslog.log shows more activity, and I have reproduced this below. Everything before and after the given point in time is too far out to be relevant:

Feb 12 22:55:17 MyPC NetworkManager[1198]: <info>  [1581548117.3612] device (p2p-dev-wlp2s0): state change: disconnected -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
Feb 12 22:55:17 MyPC whoopsie[1521]: [22:55:17] offline
Feb 12 22:55:17 MyPC NetworkManager[1198]: <info>  [1581548117.3616] manager: NetworkManager state is now ASLEEP
Feb 12 22:55:17 MyPC systemd[1]: Reached target Sleep.
Feb 12 22:55:17 MyPC systemd[1]: Starting Suspend...
Feb 12 22:55:17 MyPC kernel: [ 8812.324175] PM: suspend entry (deep)
Feb 12 22:55:17 MyPC systemd-sleep[16039]: Suspending system...

journalctl is similarly unhelpful:

Feb 12 22:55:17 MyPC NetworkManager[1198]: <info>  [1581548117.3612] device (p2p-dev-wlp2s0): state change: disconnected -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
Feb 12 22:55:17 MyPC whoopsie[1521]: [22:55:17] offline
Feb 12 22:55:17 MyPC NetworkManager[1198]: <info>  [1581548117.3616] manager: NetworkManager state is now ASLEEP
Feb 12 22:55:17 MyPC systemd[1]: Reached target Sleep.
Feb 12 22:55:17 MyPC systemd[1]: Starting Suspend...
Feb 12 22:55:17 MyPC systemd-sleep[16039]: Suspending system...
Feb 12 22:55:17 MyPC kernel: PM: suspend entry (deep)
-- Reboot --

As for solving this problem, nothing that I've seen on AskUbuntu or elsewhere online has worked:

• Blacklisting Intel modules such as mei has changed nothing of relevance.
• To my knowledge, I have no NVDIA modules to blacklist. In fact, I don't even have any options to install the drivers on the Additional Drivers menu. If there's an easy way to double-check, please comment.
• lsmod | grep nouveau suggests that I'm not running the notoriously buggy nouveau module.
• apt list --installed | grep light suggests that I'm not running the buggy lightlocker package.
• I am already using lightdm, so gdm can't be to blame.
• It has been suggested that this could be an ACPI issue, but I don't know how to approach that. As suggested by Raffa, I have placed my dmesg | grep -i acpi output here. Apparently [ 0.259633] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug and [ 1.045638] acpi PNP0C14:02: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01) are cause for concern, but I do not know how to address them.
• cat /sys/power/mem_sleep returns s2idle [deep]. I believe that this is the expected result.
• Making changes to Grub's GRUB_CMDLINE_LINUX_DEFAULT settings for the PCIe connection to my SSD has done nothing. I have tried many other suggestions for changing Grub's settings, but I've failed to keep a log of them.
• Editing SuspendState in /etc/systemd/sleep.conf has done nothing.
• Changing to older kernels, even as far back as 5.0.21-050021.201906040731 or as far forward as 5.3.0-18.19+1, has changed nothing.
• I am aware of some similar bugs in some 4.x kernels, but I'm under the impression that they've been patched in the 5.x kernels, so they shouldn't be relevant.
• Lenovo is giving me contradictory dates for when the latest BIOS update was released, but my version number (ALCN28WW(V2.05)) matches theirs and the release date that sudo dmidecode gives me matches the date that's in their readme (November 25th 2019, contrary to their website's claim of December 16th 2019).

Looking Into your dmesg | grep -i acpi output I can see what suggests that this is an ACPI issue. In particular, this:

[    1.045638] acpi PNP0C14:02: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01)
[    1.045676] acpi PNP0C14:03: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01)

WMI:

Windows Management Instrumentation (WMI) is a complex set of proprietary extensions to the Windows Driver Model that provides an OS interface to allow instrumented components to provide information and notifications.

This actually means that your machine was originally manufactured for Windows OS and although Ubuntu and other Linux distributions will mimic the Windows OS calls to the BIOS using different mechanisms amoung which WMI, there are times when this transaction is unsuccessful on ether ends and such issues happen.

The issues caused by this can range from just suspend issues to WiFi, Ethernet, battery, hard drives, SSDs and others.

Some of these issues appear with certain Linux kernels and disappear with others. They might differ but, are unlikely to disappear completely until the communication between system BIOS and the kernel is fixed. The ideal fix is a BIOS update from the manufacturer that addresses this issue.

What you can do besides that is to experiment with the hardware ie. the SSD and change the graphics drivers to open source or proprietary until the machine is stable. Also Upgrade to the next release of Ubuntu that comes next month as it might provide better support for your machines BIOS.

Best of luck