SkyLined / BugId

Detect, analyze and uniquely identify crashes in Windows applications

Home Page:https://bugid.skylined.nl

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Can't find Windows SDK Path

baptistapedro opened this issue · comments

Hello,
Does BugID look for a specific path for Windows SDK?
I have the SDK on D:\ but still throw: BugId depends on Debugging Tools for Windows which was not found.

Should I put the SDK on a specific path where BugID expects for?

Regards.

BugId automatically looks for the SDK in the default installation path. If it cannot find it there, you will get this error message. You will need to find the folder of the Debugging Tools for Windows in which cdb.exe is stored. This should be in a sub-folder of the SDK such as Windows Kits\<version number>\Debuggers\x86 (or \x64),

You can either provide the path manually through the command line or by changing the default settings.

Changing the SDK path through the command line is rather painful as you need to provide the path as a JSON encoded value and Windows requires you to double-escape everything:

BugId --cBugId.sDebuggingToolsPath_x64=\"d:\\\\Path\\\\To\\\\SDK\\\\Windows Kits\\\\10\\\\Debuggers\\\\x64\" <normal command line arguments>

or, if you are running a 32-bit version of windows:

BugId --cBugId.sDebuggingToolsPath_x86=\"d:\\\\Path\\\\To\\\\SDK\\\\Windows Kits\\\\10\\\\Debuggers\\\\x86\" <normal command line arguments>

A better and more permanent way to do this is to change the path in dxConfig.py in the root folder of BugId. At the end of the file, you will see this:

  "cBugId": {
    # The values from cBugId\dxConfig.py get loaded here unless they are provide here.
    # You can also modify these from the command line using --cBugId.<settings name>=<JSON value>
  },

You can change the path to the Windows SDK by changing the above to the below:

  "cBugId": {
    # The values from cBugId\dxConfig.py get loaded here unless they are provide here.
    # You can also modify these from the command line using --cBugId.<settings name>=<JSON value>
    "sDebuggingToolsPath_x64": r"D:\Path\To\SDK\Windows Kits\10\Debuggers\x64",
    "sDebuggingToolsPath_x86": r"D:\Path\To\SDK\Windows Kits\10\Debuggers\x86",
  },

Let me know if this works, so I can close this bug!

Yeah that works out but I found out a new error.
I did set the path on dxConfig.py directly.

I'm running the cmd as follow: python BugId.py chrome_x64 -bGenerateReportHTML=true

┌─ An internal exception has occured ──────────────────────────────────────────────────────────────────────────────────
│ AssertionError('End-of-command-output marker missing:\r\nNumeric expression missing from \'@!"chrome_child.dll!ovly_debug_event"; \'',)
│
│  Stack:
│   0 cCdbWrapper_fasExecuteCdbCommand @ C:\Users\Gitinha\Desktop\BugId\modules\cBugId\cCdbWrapper_fasExecuteCdbCommand.py/85
│      > "End-of-command-output marker missing:\r\n%s" % "\r\n".join(oEndOfCommandOutputMarkerMissingException.asCommandOutput);
│   1 fasExecuteCdbCommand @ C:\Users\Gitinha\Desktop\BugId\modules\cBugId\cCdbWrapper.py/368
│      > return cCdbWrapper_fasExecuteCdbCommand(oCdbWrapper, *axArguments, **dxArguments);
│   2 fasExecuteCdbCommand @ C:\Users\Gitinha\Desktop\BugId\modules\cBugId\cProcess.py/117
│      > return oProcess.oCdbWrapper.fasExecuteCdbCommand(sCommand, sComment, **dxArguments);
│   3 cProcess_fuGetAddressForSymbol @ C:\Users\Gitinha\Desktop\BugId\modules\cBugId\cProcess_fuGetAddressForSymbol.py/9
│      > srIgnoredErrors = gsrIgnoredErrors,
│   4 fuGetAddressForSymbol @ C:\Users\Gitinha\Desktop\BugId\modules\cBugId\cProcess.py/120
│      > return cProcess_fuGetAddressForSymbol(oProcess, sSymbol);
│   5 foCreate @ C:\Users\Gitinha\Desktop\BugId\modules\cBugId\cStack.py/241
│      > uFunctionAddress = oProcess.fuGetAddressForSymbol(oFunction.sName);
│   6 oStack @ C:\Users\Gitinha\Desktop\BugId\modules\cBugId\cBugReport.py/93
│      > oBugReport.__oStack = cStack.foCreate(oBugReport.__oProcess, oBugReport.__oWindowsAPIThread, oBugReport.uStackFramesCount);
│   7 fbApplyToBugReport @ C:\Users\Gitinha\Desktop\BugId\modules\cBugId\BugTranslations\cBugTranslation.py/98
│      > if oBugReport.oStack.fbTopFramesMatchSymbols(asAdditionalIrrelevantStackFrameSymbols, \
│   8 fApplyBugTranslationsToBugReport @ C:\Users\Gitinha\Desktop\BugId\modules\cBugId\BugTranslations\fApplyBugTranslationsToBugReport.py/53
│      > if oBugTranslation.fbApplyToBugReport(oBugReport):
│   9 foCreateForException @ C:\Users\Gitinha\Desktop\BugId\modules\cBugId\cBugReport.py/124
│      > fApplyBugTranslationsToBugReport(oBugReport);
│  10 cCdbWrapper_fCdbStdInOutHelperThread @ C:\Users\Gitinha\Desktop\BugId\modules\cBugId\cCdbWrapper_fCdbStdInOutHelperThread.py/409
│      > oException,
│  11 fCdbStdInOutHelperThread @ C:\Users\Gitinha\Desktop\BugId\modules\cBugId\cCdbWrapper.py/378
│      > return cCdbWrapper_fCdbStdInOutHelperThread(oCdbWrapper);
│  12 __fRun @ C:\Users\Gitinha\Desktop\BugId\modules\cBugId\cHelperThread.py/67
│      > oSelf.__fActivity(*oSelf.__axActivityArguments);
└──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

what is this about exaactly?

It appears that when BugId detected a crash and attempted to get the stack at the time of the crash, cdb.exe output something in a format that it does not expect. This is probably specific to the application you are testing, as I have not seen it before. I will try to work out if I can fix this, or else create a new version that reports more information about the problem to help me find out how to fix it.

Unfortunately, with the holidays comping up, it will probably be 2019 before I get around to addressing this issue. My apologies for this delay.

Is this a common behavior for OOM or do you believe is bof related?

Im testing chrome_x64.

Sorry, been real busy lately. This is not specific to a particular type of bug. It may not even be a bug: BugId analyzes certain exceptions that can happen normally when an application is running. I'll try to find soime time to see what the root cause might be soon.

When I start Chrome, I get no crash with the latest version of BugId. If you can still reproduce, please let me know what html you are using to trigger this issue so I can investigate it.