This is more of an fyi for anyone else that may come across this issue.
It appears when using CWDIllegalInDllSearch with microsofts recommend value of 0xFFFFFFFF breaks veeam. So far I've only noticed this on the veeamagent.exe, so creating an exemption will work around this issue.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\VeeamAgent.exe]
"CWDIllegalInDllSearch"=dword:00000002
https://support.microsoft.com/en-us/hel ... ontrol-the
-
- Lurker
- Posts: 1
- Liked: never
- Joined: Feb 27, 2019 7:23 pm
- Contact:
-
- Chief Product Officer
- Posts: 31814
- Liked: 7302 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Using CWDIllegalInDllSearch causes issue. Possible fix
Thank you so much for sharing this with the community!
-
- Veteran
- Posts: 528
- Liked: 144 times
- Joined: Aug 20, 2015 9:30 pm
- Contact:
Re: Using CWDIllegalInDllSearch causes issue. Possible fix
I ran into this problem with Veeam B&R with VMWare (but not Hyper-V). Veeam complains about missing C++ components in the backup job, but the linked article is not the fix. You'll find this error is present in Agent.VddkHelper.log
Changing the registry key to 2 fixed the issue, however it would be nice for Veeam to modify the way they load DLLs to be compatible with the more secure configuration.
Case # 03505422 was opened for the issue. Luckily I remembered that we had made this registry change within the last couple months (due to a Nessus vulnerability scan flagging it)
Edit: This is the KB article the error on the backup server incorrectly references https://www.veeam.com/kb2678
Code: Select all
[11.04.2019 21:36:57] < 3068> vdl| Loading VDDK library. Version: 6.7, directory: 'C:\Program Files (x86)\Veeam\Backup Transport\x64\vddk_6_7', module: 'C:\Program Files (x86)\Veeam\Backup Transport\x64\vddk_6_7', config file: ''
[11.04.2019 21:36:57] < 3068> vdl| Loading VDDK library. Version: 6.7, directory: 'C:\Program Files (x86)\Veeam\Backup Transport\x64\vddk_6_7', module: 'C:\Program Files (x86)\Veeam\Backup Transport\x64\vddk_6_7', config file: '' Failed.
[11.04.2019 21:36:57] < 3068> dsk| Unsubscribing from adapters
[11.04.2019 21:36:57] < 3068> dsk| Uninstalling redirection adapters
[11.04.2019 21:36:57] < 3068> cli| ERR |Command 'MTA VDDK API initializer' has failed.
[11.04.2019 21:36:57] < 3068> cli| >> |The specified module could not be found.
[11.04.2019 21:36:57] < 3068> cli| >> |Dynamic library cannot be loaded. Path to library: [C:\Program Files (x86)\Veeam\Backup Transport\x64\vddk_6_7\vixDiskLib.dll].
[11.04.2019 21:36:57] < 3068> cli| >> |--tr:Error code: 0x0000007e
[11.04.2019 21:36:57] < 3068> cli| >> |--tr:Failed to load VDDK library. Version: 6.7, directory: 'C:\Program Files (x86)\Veeam\Backup Transport\x64\vddk_6_7', module: 'C:\Program Files (x86)\Veeam\Backup Transport\x64\vddk_6_7', config file: ''
[11.04.2019 21:36:57] < 3068> cli| >> |An exception was thrown from thread [3068].
[11.04.2019 21:36:57] < 2628> vdl| Initializing MTA VDDK apartment Failed.
Case # 03505422 was opened for the issue. Luckily I remembered that we had made this registry change within the last couple months (due to a Nessus vulnerability scan flagging it)
Edit: This is the KB article the error on the backup server incorrectly references https://www.veeam.com/kb2678
-
- Service Provider
- Posts: 1
- Liked: never
- Joined: Dec 04, 2014 6:43 pm
- Full Name: Andrew Denton
- Contact:
Re: Using CWDIllegalInDllSearch causes issue. Possible fix
Thanks for this! We set CWDIllegalInDllSearch=0xFFFFFFFF organization-wide a long time ago. When we upgraded to Veeam update 4a recently everything broke. This fixed it!
-
- Veteran
- Posts: 370
- Liked: 99 times
- Joined: Mar 04, 2019 10:31 am
- Full Name: Stefan Zimmermann
- Location: Germany
- Contact:
Re: Using CWDIllegalInDllSearch causes issue. Possible fix
For everyone who comes here from KB2678 and is experiencing this issue on Linux proxies with VBR v12 (P20230412 in my case) when backing up: Resetting the proxy as described in KB4298 did the trick for me.
I recognized prior to reset some VDDK files were missing on my proxy (Ubuntu 20.04). /opt/veeam/transport/vddk_7_0 was an empty directory in error state, while now after reset it contains files.
I recognized prior to reset some VDDK files were missing on my proxy (Ubuntu 20.04). /opt/veeam/transport/vddk_7_0 was an empty directory in error state, while now after reset it contains files.
Kind regards, Stefan
Who is online
Users browsing this forum: Amazon [Bot] and 61 guests