windbgwindows-error-reporting

cdb/windbg output too large


We are using cdb (command line version of winDBG) to resolve a cab. For getting the output in a file we are using the -logo output to specify the output file. For a certain cab we are getting "CvRegToMachine(x86) conversion failure for 0x7536" more than a million times.
Basically we get a huge resolved code log, nearly 1GB, and all of it filled with the above string on each line.
We are using the following cdb command
cdb -z "abc.cab" -y "SymbolsPath" -G -logo "outputfile" -lines -c ".kframes 100;!analyze -v;!load msec.dll;!exploitable -v;vertarget;lmv;q"
Does anyone have any clue about what could be wrong here?


Solution

  • you cannot use -c and -G at the same time -c needs the first break to read the initial
    command and act upon it if you need to run the code use g; at the end of -c commands

    also many times -c commands need to be provided first and the debugee needs
    to be at the end of commandline

    cdb -c "<some cmd;someother cmd;g>" -z foo.cab
    

    .load not !load should be used to load third party extensions

    the string emitted "CvReg.........." seems to be related to Either SYMFLAG_NULL or SYMFLAG_REGISTER in the Flags member of SYMBOLINFO Struct .

    a sample trial didnt cross that code path in my machine so either the corrupt dmp or more information regarding the dmp file may be needed to find the reason for the spew

    creating dump

    C:\>dir /b *.cab
    File Not Found
    
    C:\>cdb -c ".dump /ma /b foo.cab;q" calc | grep -i -E "dmp|dump|wr"
    0:000> cdb: Reading initial command '.dump /ma /b foo.cab;q'
    Creating C:\DOCUME~1\Admin\LOCALS~1\Temp\foo.cab.dmp - mini user dump
    Dump successfully written
      Adding C:\DOCUME~1\Admin\LOCALS~1\Temp\foo.cab.dmp - added
    Wrote foo.cab
    
    C:\>dir /b *.cab
    foo.cab
    

    **loading dump as debugees(cdb) debuggee (foo.cab) and looking around **

    C:\>cdb cdb -z foo.cab
    
        0:000> s -u dbgeng l?39b000  "CvReg"
    020341f8  0043 0076 0052 0065 0067 0054 006f 004d  C.v.R.e.g.T.o.M.
    
    0:000> # *(*20341f8 dbgeng l?39b000
    dbgeng!MachineInfo::CvRegToMachine+0xfe:
    021bf8ae 68f8410302      push    offset dbgeng!`string' (020341f8)
    
    0:000> # call*dbgeng!MachineInfo::CvRegToMachine dbgeng l?39b000
    dbgeng!ImageInfo::CvRegToMachine+0x22:
    021b62f2 e8b9940000      call    dbgeng!MachineInfo::CvRegToMachine (021bf7b0)
    
    0:000> # call*CvRegToMachine dbgeng l?39b000
    dbgeng!ImageInfo::CvRegToMachine+0x22:
    021b62f2 e8b9940000      call    dbgeng!MachineInfo::CvRegToMachine (021bf7b0)
    dbgeng!TypeInfoValueFromSymInfo+0x4b:
    022541ab e82021f6ff      call    dbgeng!ImageInfo::CvRegToMachine (021b62d0)
    dbgeng!TypedData::SetToSymbol+0x25f:
    02285edf e8ec03f3ff      call    dbgeng!ImageInfo::CvRegToMachine (021b62d0)
    dbgeng!TypedData::SetToSymbol+0x2da:
    02285f5a e87103f3ff      call    dbgeng!ImageInfo::CvRegToMachine (021b62d0)
    0:000> ln 0x21bf8ae
    
    
    (021bf7b0)   dbgeng!MachineInfo::CvRegToMachine+0xfe   |  (021bf8d0)   dbgeng!Ma
    chineInfo::GetContextState
    

    doing and uf on this function yields the check where SymbolInfo->Flags is
    checked and decided my sample dump above doesnt enter the path