SDV used to be simple to run in the old DDK days, 7600 is the dev env I always used, but the new client has code using VS projects, so I gave it a go…
And its broken. msbuild “fail_driver1.vcxproj” /t:sdv /p:inputs=“/check /devenv” /p:configuration=“Release” /p:platform=“x64” fails with
error MSB3073: The command “staticdv /check /devenv” exited with code -1.
Note this isnt the client driver, it is the MSFT sample driver, that is explicitly set up to work with SDV
I find it hard to believe that this is just plain broken, so is there some fiendishly complex/undocumented hoop to jump through to get this to work?
Thanks all in advance
lol. This is not the first time a VS release has managed to break SDV and nobody inside MSFT noticed.
I just tried the SDV-FailDriver-KMDF sample and SDV breaks while trying to build either the associated library or the sample driver itself. The particular error is while running the linker, which oddly enough fails with error C0000409 STATUS_STACK_BUFFER_OVERRUN. Note that both the driver and the library build just fine outside of the horrible SDV ‘gui’. This abomination - the SDV gui - has been problematic for a long time.
This specific failure is:
C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(1582,5): error MSB6006: “Lib.exe” exited with code -1073740791. [C:\Users\markr\localdocs\test\multiTest\sdv-kmdf\SDV-FailDriver-KMDF\library\fail_library1.vcxproj]
link.exe has the exact same problem. -107374079 is C0000409.
Thanks for confirming that Mark.
I suppose the client could add a sources file and use the 7600 DDK, but it would be nice if MSFT could fix this. I think the client has a contact there.
Just as a follow up, I tested EWDK version co_release_svc_prod3.22000.832 (W11) which is VS2019 based, and it works. That would be a better option than the win7 WDK.