By manufacturer
Dell PowerEdge HPE ProLiant Lenovo ThinkSystem Fujitsu Primergy Supermicro IBM System x / Power Acer AltosOS stability: bringing drivers, kernel and firmware onto a single axis.
Seemingly random crashes, intermittent kernel panics, hypervisors killing VMs for no apparent reason: the symptom often looks hardware-related, but the root cause lies in the mismatch between vendor firmware, operating system drivers, power management settings and the real workload. Systemic diagnosis is what we do before replacing any hardware.
Recurring instability patterns.
- Recurring Windows BSODs with a consistent stop code (e.g.
DPC_WATCHDOG_VIOLATION,SYSTEM_THREAD_EXCEPTION_NOT_HANDLED) — often a network or storage driver out of sync with firmware. - Linux kernel panics whose stack trace always points to the same driver — the in-tree driver needs updating, or a switch to the vendor driver is required.
- ESXi PSOD (Purple Screen of Death) referencing a network, storage or RAID driver — check the VMware-vendor compatibility matrix.
- VM killed by hypervisor with no node fault: often aggressive power management putting CPU/cache into deep sleep during I/O latency.
Diagnosis before touching the hardware.
- Firmware ↔ driver alignment: vendor compatibility matrix, RAID controller, NIC, HBA, BMC.
- Power management configuration: in BIOS (C-states, P-states, Turbo) and in the operating system. Transactional servers need a "performance" power policy; idle servers may need the opposite.
- Certification checks: VMware HCL, Microsoft WHQL, Red Hat HCL for the combinations the customer is actually running.
- Crash dump analysis (Windows) or kernel log analysis (Linux) to pinpoint the exact component that is failing.
The questions we get most often.
For servers with software problems, do you handle it or is AssistenzaServer.eu the right contact?
It depends on the root cause. If diagnosis shows the symptom is hardware-related (vendor driver out of sync, firmware needing an update, BIOS power management), we handle it: the hardware/software boundary is our natural territory. If the cause is purely a sysadmin matter (application configuration, OS patching, software networking, security), the right contact is our sister site AssistenzaServer.eu.
Does updating drivers always fix the problem?
No, in some cases the newest drivers carry bugs — especially on EOL hardware, where the vendor matrix stops testing older combinations. On these systems the certified stable release is often N-1 or N-2 rather than the latest. We check the vendor matrix case by case.
Windows crash dumps or Linux kernel logs: do you always ask for them?
Yes, they are the single most important input for the diagnosis. On Windows: minidumps in C:\Windows\Minidump (enabled by default). On Linux: /var/log/kern.log, journalctl -k, plus any kdump crash files in /var/crash. On ESXi: vmkernel.log, vm-support bundle. Without them, the diagnosis is slower and less precise.