First, change the setup script to copy the DBG CRT locally. Second, please investigate if/why the service fails to load when the CRT is in system32 directory.

attempting local reproduction

setup script excepts the CRT DLL in the same location, thus copy action is a pre-step to the execution of this script hence not needed.

Observation when setting - logon as local system account the issue is not seen -

Seeing this error when using the installer to install ebpf with JIT -

- this shows that LOCAL SERVICE does not have read access to the debug dll "ending with d.dll", the reason being LOCAL SERVICE is part of Users group which is not granted read access for d.dll such as msvcp140d.dll in C:\Windows\System32 directory

You need JIT installed for Debug msi, for running Kernel programs, along with vc_redist.x64.exe

Could we copy the debug dlls to the JIT directory as a work around? (Side note: is the user expected to install the debug runtime when using an MSI without going via setup-ebpf.ps1?)

Removing the triage label because I'd like to discuss this in tomorrows meeting.

@vpidatala94 - please make changes to statically link CRT in debug bits.

this is after statically linking the debug runtime libraries to ebpf-for-windows.msi

static linking will cause breakages in a scenario where - the customer is a using a release version of the product and debug version of the EBPF product. Fix addressed parallelly here - #3957, as part of this bug updating to documentation to help customers know that if they are using debug MSI to install ebpf directly they are supposed to copy the Debug DLL to a detectable location to allow it to be loaded

@vpidatala94 if I understand you correctly you’ve tried running an application which is linked against the release runtime against an ebpfapi.dll statically linked against the debug runtime. Does this even work when dynamically linking the debug instead? I imagine that this might not be supported in the first place?

The following makes me think that mixing release and debug versions isn't really supported in the first place:

All modules passed to a given invocation of the linker must have been compiled with the same run-time library compiler option (/MD, /MT, /LD).

So the use case of a customer using the release libs with debug ebpf for windows isn't really a valid use case? That would mean we can statically link after all.

Apologies for the delay, the problem with static linking CRT is the ebpfapi.dll will have a different context compared to the Custom application (both using different sets of CRT) causing state difference/incompatibility as a result the ebpfapi.dll CRT will not be able to find the FD that customer application attempts to close. Based on discussion with Dave, the new direction we are going forth is making the debug installer more "complete" that the installer will will attempt to copy the DEBUG CRT to a set location included in path and if these are DEBUG CRT are not found, the installer will raise a warning.

@vpidatala94 please investigate if static linking against CRT works for all scenarios ( a C application loading ebpf api.dll etc.) If things turn out OK, when you change to static CRT, please revert #4014.