I'm Trying to import sockets in a lua script to make a twitch chat app inside a game.
The game implementation of lua is "Designed to work with OpenResty’s fork of LuaJIT, with LuaJIT compiled with 5.2 compatibility option." (https://github.com/ac-custom-shaders-patch/acc-lua-sdk/)
I am not familiar with lua but I have been trying to get this to work for a few days but with not much progress.
I have tried different repositories with sockets/websockets but could not get them to work.
when trying local socket = require("socket") I get the following error
[
module 'socket.core' not found: no field package.preload['socket.core']
no file '\socket\core.lua'
no file 'E:\steam\SteamApps\common\assettocorsa\ua\socket\core.lua'
no file 'E:\steam\SteamApps\common\assettocorsa\Jua\socket\core\init.lua'
no file 'C:\Program Files (x86)\Lua\5.1\Jua\socket\core.luac'
no file 'E:\steam\SteamApps\common\assettocorsa\apps\lua\My FirstApp/socket\core.lua'
no file 'E:\steam\SteamApps\common\assettocorsa\extension/internal/lua-socket\core.lua'
no file '\socket\core.dil'
no file 'E:\steam\SteamApps\common\assettocorsa\socket\core.dil'
no file 'E:\steam\SteamApps\common\assettocorsa\Vloadall.dll'
no file '.\socket.dll'
no file 'E:\steam\SteamApps\common\assettocorsa\socket.dll'
no file 'E:\steam\SteamApps\common\assettocorsa\loadall.dll' [C]: in function 'require
...mApps\common\assettocorsa\apps\lua\My FirstApp/socket.lua:12: in main chunk [C]: in function 'require'
...s\common\assettocorsa\apps\lua\My FirstApp\MyFirstApp.lua:13: in main chunk
][1]
If I understood this correctly that socket.core is normally something included in the lua language that would be installed on the machine. But I need this to be included with the app so it can be shared to other people as well.
From my understanding I need something made for lua 5.1 and compiled for windows. The game runs in 64bits by default but can be forced to 32 bits so i'm assuming ideally i'd need 2 dlls.
This is mostly why I've been trying hard to get this particular solution (https://github.com/luapower/socket) to work as they include pre build dlls which I'm assuming contain everything needed for socket to run. But I can't get the error above to go away.
I have also not been able to build my own dll due to my lack of understanding of lua and programming in general and more importantly i'm not sure what to build exactly to make sure it would work for this particular usecase.
The whole lua stuff seems to be super unfriendly to use on windows in general which only adds to my confusion so any insight on how I could proceed to get this to work would be greatly appreciated. I can supply further info neeeded.
edit: it seems that my understanding of where require was looking for files was wrong. I've moved the files to a separate folder and I now get Error: error loading module socket.core' from file '.\socket\core.dll: %1 is not a valid Win32 application. [C]: at 0x7ffd961fb3c0 [C]: in function 'require' ...s\common\assettocorsa\apps\lua\MyFirstApp\MyFirstApp.lua:16: in main chunk
So I guess it's running lua in 32 bits? I tried to grab some compiled socket/core.dll from diff repos and they all give the error.. I checked with dependency walker and some were 32 bits and others were 64bits dlls. Same error regardless.
[1]: https://i.stack.imgur.com/Mdexh.png
Note that there are no commits in [GitHub]: luapower/socket since Nov 2019. Also, the directory structure doesn't seem correct. And (something that should have been mentioned there) it was built (and runs) with Lua 5.1.
I've built v3.0.0 and placed the binaries at: [GitHub]: CristiFati/Prebuilt-Binaries - (master) Prebuilt-Binaries/LuaSocket/v3 (built with Lua 5.4.4 from the same repository, which should be used to run it).
Here's an example:
[cfati#CFATI-5510-0:e:\Work\Dev\StackOverflow\q071876058]> sopr.bat
### Set shorter prompt to better fit when pasted in StackOverflow (or other) pages ###
[prompt]> "c:\Program Files\Lua\Lua\5.4.4\bin\lua.exe" -l socket
c:\Program Files\Lua\Lua\5.4.4\bin\lua.exe: module 'socket' not found:
no field package.preload['socket']
no file 'c:\Program Files\Lua\Lua\5.4.4\bin\lua\socket.lua'
no file 'c:\Program Files\Lua\Lua\5.4.4\bin\lua\socket\init.lua'
no file 'c:\Program Files\Lua\Lua\5.4.4\bin\socket.lua'
no file 'c:\Program Files\Lua\Lua\5.4.4\bin\socket\init.lua'
no file 'c:\Program Files\Lua\Lua\5.4.4\bin\..\share\lua\5.4\socket.lua'
no file 'c:\Program Files\Lua\Lua\5.4.4\bin\..\share\lua\5.4\socket\init.lua'
no file '.\socket.lua'
no file '.\socket\init.lua'
no file 'c:\Program Files\Lua\Lua\5.4.4\bin\socket.dll'
no file 'c:\Program Files\Lua\Lua\5.4.4\bin\..\lib\lua\5.4\socket.dll'
no file 'c:\Program Files\Lua\Lua\5.4.4\bin\loadall.dll'
no file '.\socket.dll'
stack traceback:
[C]: in function 'require'
[C]: in ?
[prompt]>
[prompt]> set LUA_PATH=;;c:\Program Files\LunarModules\LuaSocket\3.0.0(Lua5.4)\?.lua
[prompt]> set LUA_CPATH=;;c:\Program Files\LunarModules\LuaSocket\3.0.0(Lua5.4)\?.dll
[prompt]>
[prompt]> "c:\Program Files\Lua\Lua\5.4.4\bin\lua.exe" -l socket
Lua 5.4.4 Copyright (C) 1994-2022 Lua.org, PUC-Rio
> -- Lua started, meaning the module was successfully loaded
> ^Z
[prompt]> :: Attempt to load the module in Lua 32bit (pc032)
[prompt]> "c:\Program Files (x86)\Lua\Lua\5.4.4\bin\lua.exe" -l socket
c:\Program Files (x86)\Lua\Lua\5.4.4\bin\lua.exe: error loading module 'socket.core' from file 'c:\Program Files\LunarModules\LuaSocket\3.0.0(Lua5.4)\socket\core.dll':
%1 is not a valid Win32 application.
stack traceback:
[C]: in ?
[C]: in function 'require'
...am Files\LunarModules\LuaSocket\3.0.0(Lua5.4)\socket.lua:12: in main chunk
[C]: in function 'require'
[C]: in ?
[prompt]> :: Module structure
[prompt]> tree /a /f "c:\Program Files\LunarModules\LuaSocket\3.0.0(Lua5.4)"
Folder PATH listing for volume SSD0-WIN
Volume serial number is 0000001F F2CE:FA29
C:\PROGRAM FILES\LUNARMODULES\LUASOCKET\3.0.0(LUA5.4)
| ltn12.lua
| LuaSocket.LICENSE
| mbox.lua
| mime.lua
| socket.lua
|
+---mime
| core.dll
|
\---socket
core.dll
ftp.lua
headers.lua
http.lua
smtp.lua
tp.lua
url.lua
As seen, I also covered the pc064 / pc032 .dll mismatch. For more details, check [SO]: Python Ctypes - loading dll throws OSError: [WinError 193] %1 is not a valid Win32 application (#CristiFati's answer).
Related
I have tried to build my udf file after adding it. I ran as follows:
tbin\win64/DOF_Sol - Copy.c to libudf\src
udf_names.c and user_nt.udf files in 2ddp_host are upto date.
(system "copy "C:\PROGRA~1\ANSYSI~1\v181\fluent"\fluent18.1.0\src\udf\makefile_nt.udf "libudf\win64\2ddp_host\makefile" ")
1 file(s) copied.
(chdir "libudf")(chdir "win64\2ddp_host")udf_names.c and user_nt.udf files in 2ddp_node are upto date.
(system "copy "C:\PROGRA~1\ANSYSI~1\v181\fluent"\fluent18.1.0\src\udf\makefile_nt.udf "libudf\win64\2ddp_node\makefile" ")
1 file(s) copied.
(chdir "libudf")(chdir "win64\2ddp_node")
Done.
Later while compling it an error is popig up.
Inc\v181\fluent\ntbin\win64\libudf"...
Error at Node 0: The UDF library you are trying to load (libudf) is not compiled for parallel use on the current platform (win64).
The system cannot find the file specified.
Error at host: The UDF library you are trying to load (libudf) is not compiled for parallel use on the current platform (win64).
The system cannot find the file specified.
C:\Program Files\ANSYS Inc\v181\fluent\ntbin\win64\libudf\win64\2ddp_host\libudf.dll
Error at Node 1: The UDF library you are trying to load (libudf) is not compiled for parallel use on the current platform (win64).
The system cannot find the file specified.
Error at Node 2: The UDF library you are trying to load (libudf) is not compiled for parallel use on the current platform (win64).
The system cannot find the file specified.
Error at Node 3: The UDF library you are trying to load (libudf) is not compiled for parallel use on the current platform (win64).
The system cannot find the file specified.
Error at Node 4: The UDF library you are trying to load (libudf) is not compiled for parallel use on the current platform (win64).
The system cannot find the file specified.
Error at Node 5: The UDF library you are trying to load (libudf) is not compiled for parallel use on the current platform (win64).
The system cannot find the file specified.
C:\Program Files\ANSYS Inc\v181\fluent\ntbin\win64\libudf\win64\2ddp_node\libudf.dll
C:\Program Files\ANSYS Inc\v181\fluent\ntbin\win64\libudf\win64\2ddp_node\libudf.dll
C:\Program Files\ANSYS Inc\v181\fluent\ntbin\win64\libudf\win64\2ddp_node\libudf.dll
C:\Program Files\ANSYS Inc\v181\fluent\ntbin\win64\libudf\win64\2ddp_node\libudf.dll
C:\Program Files\ANSYS Inc\v181\fluent\ntbin\win64\libudf\win64\2ddp_node\libudf.dll
C:\Program Files\ANSYS Inc\v181\fluent\ntbin\win64\libudf\win64\2ddp_node\libudf.dll
MPI Application rank 0 exited before MPI_Finalize() with status 2
The fl process could not be started.
error message
I have been running my fluent from vs prompt itself. I had set all the environment paths requied for the execution. The coding is working absolutly fine.
This is common if you have chosen ansys parallel run.
It should be solved by selecting the serial version at the start of Fluent.
Other way is to have PRF_GRSUMx(variable) constructs in your UDF which take care for global summation.
I wrote some code. and fixed some errors with the help of good persons.
Now, this utility(samChecker-exe.exe) works properly in Stack environment.
This utility use text-icu and I coded this utility on windows. Of course, I want to work this utility on other windows OS.
I copied %stackPath%.stack-work\install\~\bin\samCheceker-exe.exe to some other folder, and execution through CMD.
But I got error message that says "libicuuc57.dll dose not exist. so program can't start. please re-install the program."
I copied libicuuc57.dll, and so... as like programming newbies, but failed. "stack install" command was the same result.
(I installed text-icu and installed ICU lib. on windows. The input file encoded in "MS949")
With help of Francesco Ariis from (beginners#haskell.org), I stepped forward.
But still got error message.
C:\Users\shaeg\Documents\Haskell\samChecker3> stack build --ghc-options="-static -optl-static"
Warning: File listed in samChecker3.cabal file does not exist: README.md
samChecker3-0.1.0.0: unregistering (local file changes: app\Main.hs samChecker3.cabal src\Lib.hs test\Spec.hs)
samChecker3-0.1.0.0: configure (lib + exe)
Configuring samChecker3-0.1.0.0...
samChecker3-0.1.0.0: build (lib + exe)
Preprocessing library samChecker3-0.1.0.0...
[1 of 1] Compiling Lib ( src\Lib.hs, .stack-work\dist\ca59d0ab\build\Lib.o )
Preprocessing executable 'samChecker3-exe' for samChecker3-0.1.0.0...
[1 of 1] Compiling Main ( app\Main.hs, .stack-work\dist\ca59d0ab\build\samChecker3-exe\samChecker3-exe-tmp\Main.o )
Linking .stack-work\dist\ca59d0ab\build\samChecker3-exe\samChecker3-exe.exe ...
C:/Users/shaeg/AppData/Local/Programs/stack/x86_64-windows/ghc-8.0.2/mingw/bin/ld.exe: cannot find -licuuc
C:/Users/shaeg/AppData/Local/Programs/stack/x86_64-windows/ghc-8.0.2/mingw/bin/ld.exe: cannot find -licuin
C:/Users/shaeg/AppData/Local/Programs/stack/x86_64-windows/ghc-8.0.2/mingw/bin/ld.exe: cannot find -licudt
collect2.exe: error: ld returned 1 exit status
`gcc.exe' failed in phase `Linker'. (Exit code: 1)
Warning: File listed in samChecker3.cabal file does not exist: README.md
-- While building package samChecker3-0.1.0.0 using:
C:\sr\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_1.24.2.0_ghc-8.0.2.exe --builddir=.stack-work\dist\ca59d0ab build lib:samChecker3 exe:samChecker3-exe --ghc-options " -ddump-hi -ddump-to-file"
Process exited with code: ExitFailure 1
[stack path] results
extra-include-dirs: C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\include
extra-library-dirs: C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib
According to first error message(libicuuc57.dll dose not exist. so program can't start. please re-install the program.), I find the path for libicuuc57.dll, and re-set the extra-library-dirs.
C:\Users\shaeg\Documents\Haskell\samChecker3>stack build --extra-lib-dirs=C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\bin --ghc-options="-static -optl-static"
But got the same result.
libicuuc75.dll, libicuin57.dll etc files is located in C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\bin
Someones says, this is Linker Acting.
How can I fix this error?
Thank you so much.
Sincerely, S. Chang.
Here is my stack path.
C:\Users\shaeg\Documents\Haskell\samChecker3>stack path
stack-root: C:\sr
project-root: C:\Users\shaeg\Documents\Haskell\samChecker3
config-location: C:\Users\shaeg\Documents\Haskell\samChecker3\stack.yaml
bin-path: .;C:\sr\snapshots\7dd4ddea\bin;C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\bin;C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\mingw\bin;C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\bin;C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\usr\bin;C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\usr\local\bin;C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files\Intel\IntelSGXPSW\bin\x64\Release\;C:\Program Files\Intel\IntelSGXPSW\bin\win32\Release\;c:\Program Files\Intel\WiFi\bin\;c:\Program Files\Common Files\Intel\WirelessCommon\;C:\Program Files\Hewlett-Packard\SimplePass\;C:\Users\shaeg\AppData\Roaming\local\bin;C:\Users\shaeg\AppData\Local\Microsoft\WindowsApps
programs: C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows
compiler-exe: C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\bin\ghc.EXE
compiler-bin: C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\bin
local-bin: C:\Users\shaeg\AppData\Roaming\local\bin
extra-include-dirs: C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\include
extra-library-dirs: C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib
snapshot-pkg-db: C:\sr\snapshots\7dd4ddea\pkgdb
local-pkg-db: C:\Users\shaeg\Documents\Haskell\samChecker3\.stack-work\install\02136e14\pkgdb
global-pkg-db: C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib\package.conf.d
ghc-package-path: C:\Users\shaeg\Documents\Haskell\samChecker3\.stack-work\install\02136e14\pkgdb;C:\sr\snapshots\7dd4ddea\pkgdb;C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib\package.conf.d
snapshot-install-root: C:\sr\snapshots\7dd4ddea
local-install-root: C:\Users\shaeg\Documents\Haskell\samChecker3\.stack-work\install\02136e14
snapshot-doc-root: C:\sr\snapshots\7dd4ddea\doc
local-doc-root: C:\Users\shaeg\Documents\Haskell\samChecker3\.stack-work\install\02136e14\doc
dist-dir: .stack-work\dist\ca59d0ab
local-hpc-root: C:\Users\shaeg\Documents\Haskell\samChecker3\.stack-work\install\02136e14\hpc
local-bin-path: C:\Users\shaeg\AppData\Roaming\local\bin
ghc-paths: C:\Users\shaeg\AppData\Local\Programs\stack\x86_64-windows
I was able to test it recently, and share my solution.
First of all, I assume environment of latest msys2 which is installed mingw64/mingw-w64-x86_64-icu 57.1-2 package.
Dynamic linking
Executable which dynamically linked has dependencies to libgcc_s_seh-1.dll libicudt57.dll libicuin57.dll libicuuc57.dll libstdc++-6.dll libwinpthread-1.dll under stack's msys2 mingw64/bin path. If you have already built dynamic linked executable, copying all of them to same directory will solve the problem.
Dependency walker in my comment can help to reveal all of these dependencies.
Static linking
Currently text-icu package doesn't seem to support static linking. So we should modify it ourselves. If you don't know how to make it into local package, note the third option of this.
Modify text-icu-0.7.0.1's .cabal file extra-libraries section to the following.
extra-libraries: sicuin sicuuc sicudt
-- if os(mingw32)
-- extra-libraries: icuin icudt
-- else
-- extra-libraries: icui18n icudata
Append -pgmlC:\Users\[USERNAME]\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\mingw\bin\g++.exe to your executable's ghc-options cabal entry. This is required to link to ICU's C++ symbols.
Then just do stack build.
I followed all the instruction mentioned in https://github.com/cisco/openh264 but I am unable to get through. The information is cited in link but its quite confusing.
Alternative Way:
You can build Openh264 using visual studio in windows. Here are the steps..
i) Download OpenH264 source code provided by cisco (that already you
mentioned https://github.com/cisco/openh264).
ii) Now you will find two visual studio compatible projects in
directory /OpenH264/codec/build/win32/dec and
/OpenH264/codec/build/win32/enc.
iii) You will need to download NASM software from http://www.nasm.us/pub/nasm/releasebuilds/2.12.02/
iv) Install NASM software on the directory C:\NASM or wherever you like.
v) Then Add NASM executable path to all these visual studio projects.
vi) Then You can either select static or dynamic library in general
options.
vi) If you are able to perform all these operations successfully, you will have 5 different .lib or .dll files named welsdcore, welsdecplus, welsecore, welsencplus, welsvp and those
are usable in any visual studio projects.
Now if you want to get openh264 features, just add all these libraries to your project and enjoy.
Hope it will help you.. :)
I also had some difficulty building openh264 on Windows using the recommended mingw approach.
In my case make crashed for all configurations I tried:
bash -c "make OS=msvc ARCH=x86_64 USE_ASM=No BUILDTYPE=Debug clean"
bash -c "make OS=msvc ARCH=x86_64 USE_ASM=No BUILDTYPE=Debug"
0 [main] make 3888 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
564 [main] make 3888 open_stackdumpfile: Dumping stack trace to make.exe.stackdump
0 [main] make 5448 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
561 [main] make 5448 open_stackdumpfile: Dumping stack trace to make.exe.stackdump
copying dll files to destination folder...
FullDestDir is E:\projects\openh264\bin\x64\Debug
current dir is:
E:\projects\openh264
DestDir is bin/x64/Debug
cp: cannot stat `openh264.dll': No such file or directory
cp: cannot stat `openh264.lib': No such file or directory
cp: cannot stat `openh264.pdb': No such file or directory
cp: cannot stat `codec_unittest.exe': No such file or directory
cp: cannot stat `h264enc.exe': No such file or directory
cp: cannot stat `h264dec.exe': No such file or directory
BuildDebugFlag =1
BuildReleaseFlag =0
BuildDebugInfo ="build debug--failed"
BuildReleaseInfo =NULL
aBuildFlagList is 1 0
ReturnCode is 1
I resorted to converting the existing solution/projects (VS2008) to VS2013 and linking/building with the created .lib files.
You can find the solutions in {openh264_dir}\codec\build\win32\enc and {openh264_dir}\codec\build\win32\dec.
Building the solution will create .libs and .dlls in {openh264_dir}\bin\Win32\Release
To link to the lib, you need to link to welsenc.lib.
When running, you need to have both the welsenc.dll and welsvp.dll in your application directory. So far it seems to have worked fine for my usage.
I'm assuming that building the decoder will be similar.
I am trying to use Teamcity as Symbol Server. I set Up TC like I should and TC is indexing my files.
I found THIS question so I tried it to find the symbols on the server. I get some .dll listed with the command symchk /r * /s SRV*http://outserver.acp.net/app/symbols. I Only see other dlls but not my libraries or pdbs.
What did i miss?
A short Log:
[14:45:48]Indexing sources appeared in file C:\BuildAgent\work\8652c4bdd8dd2154\***\File.pdb
[14:45:48]Information about 7 source files was updated
[14:45:53]Collecting symbol files signatures.
[14:45:53]Running command C:\BuildAgent\plugins\symbol-server\bin\JetBrains.CommandLine.Symbols.exe dumpSymbolSign /o="C:\BuildAgent\temp\buildTmp\symbol-signatures-8701232224987713334.xml" /i="C:\BuildAgent\temp\globalTmp\dumpSymbolSign5535309674029756055.input"
I am making a driver official for Windows 7 as it it unsigned and the process to disable things to make the unsigned driver work is much more hassle then to actually sign the driver.
Well, in order to sign the driver, first I need to make the catalog file for the driver using the latest Inf2Cat from the Windows Driver Development Kit, all is going really well and there are no warnings but there is one error -
C:\Users\User\Downloads\dsdriv\dsdriv>"C:\Program Files (x86)\Windows Kits\8.1\bin\x86\Inf2Cat.exe" /driver:C:\Users\Support\Downloads\dsdriv\dsdriv /os:XP_X64,Server2003_X64,Vista_X64,
7_X64
................................
Signability test failed.
Errors:
22.9.12: INF file (\driver.inf) cannot be copied to %windir%\inf.
Warnings:
None
I've look around Google and I found results of where people have has similar errors but the solution was not explained, then I tried to use the Chkinf.bat utility that comes with the kit to help me find the error with the INF file but I came across a very strange error that the syntax of the command was incorrect, however I wrote the batch to check the INF file exactly to the Chkinf Documentation and yet it was still coming up with the syntax error, here is the bat that I compiled to check the driver.inf file -
"C:\Program Files (x86)\Windows Kits\8.1\Tools\x86\ChkInf\chkinf" "C:\Users\User\Downloads\dsdriv\dsdriv\driver.inf"
I also tried -
"C:\Program Files (x86)\Windows Kits\8.1\Tools\x86\ChkInf\chkinf.bat" "C:\Users\User\Downloads\dsdriv\dsdriv\driver.inf"
and -
"C:\Program Files (x86)\Windows Kits\8.1\Tools\x86\ChkInf\chkinf" C:\Users\User\Downloads\dsdriv\dsdriv\driver.inf /L results.txt /B /LO
but no use.
The ChkInf may not be present in any of the above directories. It is shipped along the WinDDK.
You can find it exactly at
WinDDK_InstalledPath\Version_of_WinDDK\tools\Chkinf\chkinf.bat
The issue could be due to the [SourceDisksFiles] containing INF copy directives