"A mismatch between the PNP/INF version and the KMD file version on the graphics adapter has been detected" - windbg

I've been testing a UMDF IddCx video driver, and this message just started appearing (after devcon.exe install ...) along with a breakpoint in WinDbg:
(DriverEntry and EVT_WDF_DRIVER_DEVICE_ADD handlers succeed as they did prior to this error message)
.
.
.
<==CDriver::OnWdfDriverDeviceAdd [status: STATUS_SUCCESS]
A mismatch between the PNP/INF version and the KMD file version on the graphics adapter has been detected. The adapter will fail to start.
(WinDbg breaks here -- see stack below)
==>CAdapter::OnWdfDeviceD0Entry(hWdfDevice: <hWdfAdapterDevice>, previousState: 5)
.
.
.
Stack info (Windows 10 Pro | Test Mode | Build 19041.vb_release.191206-1406):
[0x0] dxgkrnl!DpiFdoValidateKmdAndPnpVersionMatch + 0x88e5c
[0x1] dxgkrnl!DpiFdoInitializeFdo + 0x313
[0x2] dxgkrnl!DpiAddDevice + 0x1942
[0x3] nt!PpvUtilCallAddDevice + 0x3b
[0x4] nt!PnpCallAddDevice + 0x94
[0x5] nt!PipCallDriverAddDevice + 0x827
[0x6] nt!PipProcessDevNodeTree + 0x333
[0x7] nt!PiRestartDevice + 0xba
[0x8] nt!PnpDeviceActionWorker + 0x46a
[0x9] nt!ExpWorkerThread + 0x105
[0xa] nt!PspSystemThreadStartup + 0x55
[0xb] nt!KiStartSystemThread + 0x28
I don't understand what this means; I haven't changed anything in the INF, and this is a UMDF driver, so what "KMD file version" is it referring to? I searched for the message itself and also DpiFdoValidateKmdAndPnpVersionMatch, but came up empty.
EDIT: (adding version info)
Windows Version Info:
---------------------
Edition ....... Windows 10 Pro
Version ....... 20H2
Installed on .. 1/5/2021
OS build ...... 19042.685
Experience .... Windows Feature Experience Pack 120.2212.551.0
Can anyone shed light on this?

the Symbol Doesn't Exist in 1909 so that symbol must be a new addition to 20H2
anyway the string in question does exist in 1909
the Failure is supposedly propagated after IoQueryFullDriverPath() and GetFileVersion()
the int3 is Hardcoded after the DebugPrintEx()
the function in question ADAPTER_RENDER::Initialize() is doing a lot of comparisons with hardcoded DWORDS like 'QCOM' etc
C:\> radare2 -Q -qq -c "fs strings;f~mismatch" c:\Windows\System32\drivers\dxgkrnl.sys
0x1c0076940 139 str.A_mismatch_between_the_PNP_INF_version_and_the_KMD_file_version_on_the_graphics_adapter_has_been_detected._The_adapter_will_fail_to_start.
C:\> radare2 -A -Q -qq -c "axt 0x1c0076940" c:\Windows\System32\drivers\dxgkrnl.sys
fcn.1c015be84 0x1c0181f01 [DATA] lea r8, str.A_mismatch_between_the_PNP_INF_version_and_the_KMD_file_version_on_the_graphics_adapter_has_been_detected._The_adapter_will_fail_to_start.
i was just googling around look for something related to inf and GetKmdFileVersion and it seems you need to provide a specific Version String
see if you comply with this
specifically quoting from the doc
Drivers will report WDDM 2.1 support through
DXGK_DRIVERCAPS::WDDMVersion with a new version constant:
DXGK_WDDMVERSION::DXGKDDI_WDDMv2_1 = 0x2100 Dxgkrnl will not use the
WDDMVersion cap as a way to determine which new features are
supported—that task will be left to other caps or DDI presence.
However, if the driver reports WDDM 2.1 support through the
WDDMVersion cap, dxgkrnl will validate that caps or DDIs required by
WDDM 2.1 are present and fail to create the adapter if they are not.
Inconsistent caps will result in failure to create adapter or segment.

Please try adding the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers\DisableVersionMismatchCheck = 1 [DWORD Type]

Related

Program and Run PIC18 with pickit4 on linux

I am on linux ubuntu and target is a PIC18F47J53.
I basically want to program the chip and then let it run, using command lines and using pickit4.
using ipecmd (from mplab x ide v5.45), this is my command:
/opt/microchip/mplabx/v5.45/sys/java/zulu8.40.0.25-ca-fx-jre8.0.222-linux_x64/bin/java -jar /opt/microchip/mplabx/v5.45/mplab_platform/mplab_ipe/ipecmd.jar -TPPK4 /P18F47J53 -M -F"/path_to_myfile.hex" -W
This is my output
DFP Version Used : PIC18F-J_DFP,1.4.41,Microchip
*****************************************************
Connecting to MPLAB PICkit 4...
Currently loaded versions:
Application version............00.06.66
Boot version...................01.00.00
Script version.................00.04.17
Script build number............db473af2f4
Tool pack version .............1.6.961
PICkit 4 is supplying power to the target (3.25 volts).
Target device PIC18F47J53 found.
Device Revision Id = 0x1
*****************************************************
Calculating memory ranges for operation...
Erasing...
The following memory area(s) will be programmed:
program memory: start address = 0x0, end address = 0x3ff
program memory: start address = 0x1fc00, end address = 0x1fff7
configuration memory
Programming/Verify complete
Program Report
30-Jan-2021, 12:54:41
Device Type:PIC18F47J53
Program Succeeded.
Operation Succeeded
All good, and takes about 12 seconds, however, after that the pickit4 turns off the power target, and the pickit LED is BLUE (I guess state "ready")
The main question is how can I let the pickit4 powering the boards? any specific parameter? (I cannot find on the readme.html)
If I use MPLAB X IPE GUI to program, the programming is much quicker (3 or 4 seconds), the pickit LED is YELLOW and the target is left powered on. (I selected "release from reset")
I have tried to get the log out with as many details as possible, but I cannot see the commands sent to the pickit4.
Any idea? thanks
I realize that it's been a while since you asked, but i put the answer here for anyone who needs it. Add -OL to your command line options.

Reversing a hash to find something which works, but hashcat seems to have issues

I saw some unfamiliar code on a project i was working on.
I saw a function which said:
var salt = 1514691869198;
var result hex_hmac_sha1(salt, hmac_sha1(password))
# result is: 462435F34EAD6BB7C70751D90984DADD90EED9A4
I was having some issues with hashcat though. It seems to be getting killed early because of a driver or something.
It seems that option -m160 would be the one I would want to use since 160 = HMAC-SHA1 (key = $salt) in the man page for it.
Given the sha1.js file i was looking at, which gave me the code above, it showed the salt as the key which makes me think the 160 code as the most relevant.
Obviously this is a nested sha, but trying to find something to reverse it would be ideal.
I am aware reversing a hash would not return the actual password, but I figured I could run a wordlist and attempt to find a hash which matches this one.
That being said, I was thinking I can find a string which works. I am having issues though building either the hashcat command or finding this answer in general. I was not sure how i would want to put the hash in the command. I was thinking it would be along the lines of:
hashcat -m160 462435F34EAD6BB7C70751D90984DADD90EED9A4: 1514691869198 mywordlist.txt
but it seems to fail for me with the following:
* Device #1: Not a native Intel OpenCL runtime. Expect massive speed loss.
You can use --force to override, but do not report related errors.
No devices found/left.
Started: Sat Dec 30 22:52:33 2017
Stopped: Sat Dec 30 22:52:33 2017
and if i used --force it would say:
hashcat (pull/1273/head) starting...
OpenCL Platform #1: The pocl project
====================================
* Device #1: pthread-Intel(R) Core(TM) i7-4770HQ CPU # 2.20GHz,
2656/2656 MB allocatable, 1MCU
Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13
rotates
Rules: 1
Applicable optimizers:
* Zero-Byte
* Not-Iterated
* Single-Hash
* Single-Salt
Watchdog: Hardware monitoring interface not found on your system.
Watchdog: Temperature abort trigger disabled.
Watchdog: Temperature retain trigger disabled.
* Device #1: build_opts '-I /usr/share/hashcat/OpenCL -D VENDOR_ID=64 -D CUDA_ARCH=0 -D VECT_SIZE=1 -D DEVICE_TYPE=2 -D DGST_R0=3 -D DGST_R1=4 -D DGST_R2=2 -D DGST_R3=1 -D DGST_ELEM=5 -D KERN_TYPE=160 -D _unroll -cl-std=CL1.2'
* Device #1: Kernel m00160_a0.0bbec6e5.kernel not found in cache! Building may take a while...
Kernel library file /usr/share/pocl/kernel-i686-pc-linux-gnu.bc doesn't exist.
Try reading How to use hashcat on CPU only
Relevant parts:
Download latest OpenCL Drivers and Runtimes for CPU:
https://software.intel.com/en-us/articles/opencl-drivers#latest_CPU_runtime
Latest release (16.1.1) – at time of writing

Liquid Soap 1.1 vs 1.3 - Dynamic playlist

Scenario:
Ubuntu 17.04
Liquid Soap 1.1.1 installed by apt-get
Liquid Soap 1.3.1 installed by OPAM
On 1.1.1, I cannot use AAC+ encoder. So I've installed 1.3.1 with AAC+ support. But using a same .liq file, both versions act different.
For some reason, 1.1 works, 1.3 not:
def my_request_function() =
# Get the first line of my external process
result = list.hd(get_process_lines("php -q liquid.php"))
# Create and return a request using this result
request.create(result)
end
Error:
At line 17, char 24:
this value has type
(default:_)->_ (inferred at line 15, char 19-58)
but it should be a subtype of
string
I want to read the "next song" from a PHP script. On 1.1.1 works with MP3 (+icecast2), but since I need AAC+, I'm using 1.3.1, that I cannot figure out how to read the external script.
Any ideas? Thank you.
1.3 had another argument added to list.hd and other list functions.
https://github.com/savonet/liquidsoap/blob/master/CHANGES#L52
You can update your code with the new default value argument and it should work.
result = list.hd(default="", get_process_lines("php -q liquid.php"))

OpenCobol & PostgreSQL on Windows with Visual Studio

I'm currently facing a problem with this team of 4.
Using binaries I downloaded on kiska's site. I'm able to compile cobol to C and run it with cobcrun or compile it to an executable. However I can 't get opencobol to find the postgres commands.
Here is the strat of my cobol script :
identification division.
program-id. pgcob.
data division.
working-storage section.
01 pgconn usage pointer.
01 pgres usage pointer.
01 resptr usage pointer.
01 resstr pic x(80) based.
01 result usage binary-long.
01 answer pic x(80).
procedure division.
display "Before connect:" pgconn end-display
call "PQconnectdb" using
by reference "dbname = postgres" & x"00"
by reference "host = 10.37.180.146" & "00"
returning pgconn
end-call
...
the call PQconnectdb fail with module ont found : PQconnectdb
I noticed that if i rename the libpq.dll the error message change to can't find entry point. So at least I'm sure it can get my dll.
After digging into the code of the call method of the libcob library. I found it it was possible to pre load some dll using an environment variable COB_PRE_LOAD but sitll no results.
Here is what look the script to compile the cobol :
call "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64\vcvarsamd64.bat"
set COB_CONFIG_DIR=C:\OpenCobol\config
set COB_COPY_DIR=C:\OpenCobol\Copy
set COB_LIBS=%COB_LIBS% c:\OpenCobol\libpq.lib
set COB_LIBRARY_PATH=C:\OpenCobol\bin
set COB_PRE_LOAD=C:\OpenCobol\libpq.dll
#echo on
cobc -info
cobc -free -o pgcob -L:"C:\OpenCobol" -llibpq.lib test_cobol\postgres.cob
call cobcrun pgcob
I don't see anything missing, I'm using the 64-bit binaries from kiska's site and use the 64-bit cl.exe from Visual Studio, Postgres is a 64 bit version too (checked with dependencyChecker).
I even tryed to compile the generated C from Visual Studio, same result, but I may miss something, I'm pretty rotten in C and never really had to manage DLL or use Visual Studio.
What am I missing ?
COB_PRE_LOAD doesn't take any path or extension, see the short documentation for the available runtime configurations. I guess
set COB_LIBRARY_PATH=C:\OpenCobol\bin;C:\OpenCobol
set COB_PRE_LOAD=libpq
Will work. You can omit the C:\OpenCobol\bin if you did not placed any additional executables there.
If it doesn't work (even if it does) I'd try to get the C functions resolved at compile time. Either use
CALL STATIC "PQconnectdb" using ...
or an appropriate CALL-CONVENTION or leave the program as-is and use
cobc -free -o pgcob -L"C:\OpenCobol" -llibpq -K PQconnectdb test_cobol\postgres.cob
From cobc --help:
-K generate CALL to <entry> as static
In general: the binaries from kiska.net are quite outdated. I highly suggest getting newer ones from the official download site or ideally build them on your own from source, see the documentation for building GnuCOBOL with VisualStudio.

Dump file + PDB files - is it possible to create dump on one PC and then investigate it on another?

One certain problem is only reproducible on customer side.
We cannot reproduce it locally despite all our attempts.
But I know that TaskMgr in Windows 2008 R2 has a possibility to create dump file for a process. So, my question: is it possible to create dump on customer site for a certain process of our software and then investigate that dump file locally?
We already made a new build of our software (we saved a build sandbox and *.PDB files for all binaries). Then we installed that on site and now we are waiting when customer report that problem happens again so we will create a dump file for hanging process and then try to investigate it.
My question has 2 parts:
Would such method work at all?
If yes - how exactly to do that?
At the moment I have some doubt if that would work. Because I have tried to create a proof-test on my local Win 2008 R2 VM. I build all with .PDB files, then I run our software in a mode when it makes a long pause in the middle and I clicked "Create Dump File" in TaskMgr exactly when it does a pause (its simple call of Sleep(30000)). Then I tried to load that dump file in WinDbg and check what I could find there. First thing which makes me pessimistic about such way is a wrong stack trace. In particular - I cannot see a full stack trace in WinDbg. It shows me only stack trace for wow64.dll and ntdll.dll modules, I cannot see stack trace for our code.
In particular I see only this:
wow64cpu!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu!TurboDispatchJumpAddressEnd+0x56b
wow64!Wow64SystemServiceEx+0x1ce
wow64!Wow64LdrpInitialize+0x42a
ntdll!RtlUniform+0x6e6
ntdll!RtlCreateTagHeap+0xa7
ntdll!LdrInitializeThunk+0xe
But when I try to attach process with debugger I see a full call-stack, like this:
ntdll.dll! 7754fd910
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!7754fd9l0
KernelBase.dll! 76ae3bd50
KernelBase.dll! 76ae44a 5Q
ScrVm.DLL!Profiler::DoSleep(intmilliseconds=30000) Line 205
ScrVm.DLL!Script::VmToolKit::iMethod_Sleep(unsigned char & han
ScrVm.DLL!CComponent::Invoke(const _SU::basic_string<char,std
ScrVm.DLL!Script::VirtualMachine::do_Invoke(Script::VmCommand
ScrVm.DLL!Script::VirtualMachine::InnerLoop( Line 4471
ScrVm.DLL!Script::VirtualMachine::Execute(unsigned long hFunc=
ScrVm.DLL!ScriptProcessor::Run(const _SU::basic_string<char,st
ScrVm.DLL!ScriptProcessor::ProcessDocumentO Line 285 + 0x40 by
ScrVm.DLL!DocumentProcessor::Process(BinaryDOM::Document * pDo
ScrVm.DLL!CFuncExecScript::ExecuteO Line 219
ScrVm.DLL!SrvManager::ExecuteO Line 586 +0xldbytes
ScrVm.DLL!SrvManager::Run(tag_TReqHdr "pRequestBuf=0x00187
ScrVm.DLL!SrvManager::HandleRequest(tag_TReqHdr " pRequest
ScrVm.DLL!SrvProcessRequest(tag_TReqHdr * pRequesffiuf=0x0
ScrVm.DLL!ProcessRequest(char "pRequesffiuf=0x001873b6, char "
ScrVm.DLL!ProcessRequest_DLL(char " achMsg=0x001873b6, char "a
siteExec212.exe!00409b2d0
siteExec212.exe!0040a4cfO
As you can see WinDbg seems only showing last 7 items in stack which are useless for me. Question - is it possible to discover the full stack trace from dump file created in TaskMgr in Windows 7/2008? Or at least - I need more items in stack trace, to see from what place in our code this call was made.
Note: compiler MS VisualStudio 2008, WinDbg 6.12 x64.
Since your process is 32 bit you must use the 32 bit version of Task Manager to create the dump. Default installs have it in C:\Windows\SysWow64\taskmgr.exe
Also, make sure to use the 32 bit version of windbg.