Version 6 GA recovery problem - BUG

[alea_acp]

This is my problem (on 2 different machines).
Target machines are both Windows 10 22H2
Backup image restored (bare metal recovery) with version 6 GA (version 960) recovery image.
Reboot...recovery loop...with error.
Reading the error log from the recovery process there is a problem with this file: KDNIC.SYS
By the size the restored file is from Windows 11 and not the Windows 10 version.
I did overwrite the file with the correct version from a Working 10 22H2 machine and the reboot was successfull.
I did not test with other Windows 10 or 11 versions, at this time this was my task to solve.
Hope this helps somebody.

[Dima P.]

Hello and thank you for your post Sandro!

Mind me asking if the restore was performed to the original location or now? Also wondering if the same machine was used to create recovery media as it feels like a driver mismatch issue. Thank you!

[alea_acp]

Original location, yes for one (broken SSD replaced on the same machine) and no for the other, notebook with faulty board restored to another machine.
I have to check personally the other question, maybe this may be the issue...
I will be back in the next days with the findings.

[Dima P.]

Awaiting for your feedback. Thank you Sandro!

[alea_acp]

Test 1 done now from scratch:
- Windows 10 22H2, created from scratch USB recovery in the new installed machine and backup image done all with agent 6 GA version 960
- replaced disk with a new one, boot from USB recovery, bare metal restore (the machine is the same one, no change in hardware, only a new disk)
- boot....loop...error
Restored kdnic.sys is not the one from Windows 10 22H2 (33.296 byte) but is the one from Windows 11 22H2 (70.992 byte)
I did replace manually the file in c:\Windows\System32\drivers\kdnic.sys and Windows started without problems.
Now I'm pretty sure it's a BUG at least with the Windows 10 22H2 recovery.

Test 2: same as the above, only one difference: Windows 11 22H2, backup & restore without problems.

[boni23]

Was this BUG fixed?
Is there an official walk-around?

We're facing the exact same scenario.

Thanks!

[rmtek]

Hello,

I had the same problem today. On the source system the kdnic.sys is 33,296 bytes in size and then on the target system it is 70,992 bytes in size.

So it's obviously a bug in Veeam Backup Agent for Windows that replaces the source driver file: kdnic.sys

Veeam Backup Agent for Windows Version: 6.0.2.1090
Sorce Windows Version: Windows 10 Pro 22H2 Build 19045.3570
Source Hardware: Dell Latitude 3350
Target Hardware: HP ProBook 450 G10

Solution from alea_acp:
Overwrite the kdnic.sys with the correct version from a Working 10 22H2 machine.
(location: C:\Windows\system32\drivers\kdnic.sys)

Greetings, Ron

[Dima P.]

Hello folks,

We've investigated the previous symptoms but were not able to confirm it. If you face this issue please raise a support case and share the case ID in this thread, so QA team could review your debug logs. Thank you!

[mjr.epicfail]

Hi Dima,

I can confirm this issue, at least that its an issue.
See support case 07085935

Scenario 1 - FAILED
- Installed windows 10 fresh on a physical machine (no bitlocker)
- Backed up new full back-up to local flashdrive with Agent version 6.1.0.349
- Wipe all partitions
- Restored with agent version 6.0.2.1090
- Result: System in bootloop / repairmode

Scenario 2 - FAILED
- Production backup with agent version 6.0.2.1090
- Wipe all partitions
- Restored production backup from CloudConnect (12.1) with agent version 6.1.0.349
- Result: System in bootloop / repairmode

Scenario 3 - Success
- Installed windows 10 fresh on a physical machine (no bitlocker)
- Backed up new full back-up to local flashdrive with Agent version 6.1.0.349
- Wipe all partitions
- Restored with agent version with Agent version 6.1.0.349
- Result: System in bootloop / repairmode

Scenario 4 - Success
- Production backup with agent version 6.0.2.1090
- Test hardware: Wipe all partitions
- Restored production backup from local flashdrive with agent version 6.1.0.349
- Result: System boot successfully

[Dima P.]

Hello Danny,

Please keep working with our support team to pin point the root cause of this issue. I'll share your case details with QA team as well. Thank you so much for the update!

[M-M-C]

While trying to migrate some home-lab servers to proxmox I had the same bug.
However I guess I found the root cause.
kdnic.sys is part of "Microsoft Kernel Debugger Network Miniport", and this driver is always active, even when there are no NICs installed. If you check "inject drivers" veeam actually ALWAYS integrates "Microsoft Kernel Debugger Network Miniport" driver from the boot disk. If your boot disk is a different Windows-Version than the one you are trying to restore you'll get problems. In my case I tried to restore a Server 2022 with a boot disk I created with Win11 23H2.
Restoring without injected drivers worked fine-ish, I got "inaccessable boot device" and had to integrate storage-drivers by hand.
My suggestion for the next veeam update: put a check box in front of every driver, so the user can decide what gets injected and what's unneccessary. Maybe don't try to force-integrate and overwrite already build-in drivers...

[Dima P.]

Hello Ralf,

Glad you nailed it and thank you for your feedback! We will review it with RnD folks!