Proxmox, Windows Server 2019, SPR3 problem

[maxreds]

Hello everyone,

I would like your help to solve a problem with Proxmox.
We are trying to run a software dedicated to the collection and sending of production data on knitting looms.
The software called SPR3 is part of a suite created by SHIMA SEIKI Japan. SPR3 is installed on Windows Server 2019 virtualized on Proxmox.
At first we thought it was a problem of the USB Dongle (Sentinel manufacturer) which protects the software from unauthorized copying. Actually the dongle has always been regularly detected by Proxmox, VM and Sentinel USB drivers in Windows Server 2019. We also installed the key on a physical PC and shared with a server / client software (USB Redirector) which makes USB devices visible on the ethernet network.

According to the manufacturer of SPR3 (SHIMA) their application is compatible with VMware and Hyper-V. To verify the integrity of the Windows Server 2019 VM we have moved and converted the disk images of the VM created in Proxmox in VMware. The SPR3 software on the VM created in VMware works without problems.

Proxmox installation description
• Operating system to be virtualized Microsoft Windows Server 2019 Standard edition - 64-bit, MS2019 Standard Edition
• Dell PowerEdge T640 Hardware / Chassis Tower 8x 3.5 "HotPlug / Xeon Gold 5218 20 Core / 96GB Ram / 5x960Gb SSD SAS l / DVD RW / On-Board LOM DP / PERC H740P RAID Controller + / iDRAC9 Ent / Dual, Hot-plug, BOSS controller card + with 2 M.2 Sticks 240G (RAID 1 Redundant Power Supply 750W,
• The data collection is performed by the SPR3 application of the Shima KnitPLM suite which is certified for operation in a VMware or hyper-V environment. The application uses a Sentinel USB dongle for license validation
• Windows Server 2019 was installed on Proxmox 6.4.x starting from ISO and the proxmox VIRTIO-win 0.1.190 tools were installed
• Windows server has no malfunction
• Shima KnitPLM suite installed with no apparent errors
• The Sentinel USB Dongle is recognized and the SPR3 license is valid

Problem encountered:
• When starting SPR3 an error is displayed, the translation of which is: "Address 00000000 at address 080F00AB in modul connector.dll. there was a read violation again. ". Attached photo of the error in the original language "SPR3 error message.png".
• The application does not start and no feedback is released in the windows logs. In the log (Event Viewer) of the applications and the system we do not find any trace of the error generated by the Shima DLL


Alternative test in Vmware environment
• On the same server installed on secondary array, Vmware ESXi version VMware-VMvisor-Installer-7.0.0.update02-17867351.x86_64-DellEMC_Customized-A03.
• Extracted volumes from Qcow2 and converted the same Windows Server 2019 VM from Proxmox to Vmware
• connected the software Sentinel USB dongle to the VMware virtual machine
• The Sentinel USB Dongle is recognized and the SPR3 license is valid
• Windows server starts correctly and the SPR3 application of the Shima KnitPLM suite starts without errors

Hypothesis:
• In Proxmox, the drivers used for para-virtualization cause the problem described.

thank you.
With best regards

 

[dcsapak]

i would contact the vendor of the software, they are the only ones really capable of solving such issues

 

[maxreds]

We have tried to contact the software manufacturer. Unfortunately the manufacturer certifies the compatibility of its only with Vmware and Hyper-V. We have no possibility of a dialogue. In the test where I moved the proxmox VM to Vmware., But had given the hope of being able to intervene on the configuration of the VM in Proxmox. I tried on Proxmox to set up the VM without Virtio drivers with:
Host CPU
VGA Display (Std)
SCSI Controller Default (LSI 53C895A)
Hard Disk ide
Network Device e1000
But I have not solved. Are there any other Proxmox parameters that can make the VM even as standard as possible?

 

[dcsapak]

Are there any other Proxmox parameters that can make the VM even as standard as possible?

what do you mean by 'standard'

if the software expects something that is only available in vmware or hyper-v, and without knowing what the software wants or what fails, there is nothing we can do really
you can ofc try every option left available (e.g. bios/uefi, machine type and so on), and set some to 'vmware compatible' (e.g. display, scsi,..)

but if nothing of that works, and nobody else knows anything about it, it seems you're out of luck