I'm working with a program that generates a lot of code at runtime, and seems not to produce any unwind data for it. (I don't have source code for this program; I'm writing a plugin for it.)
When the program hangs, I break into it with WinDbg, and try to get a stack trace for all threads with ~* k. As well as the stack traces, I also get pages and pages (and pages, and more) of messages along the line of
Unable to read dynamic function table entry at 00000000`2450b580
This takes a long time to print - over a minute - and it overflows the scroll buffer, so I lose most of the output.
I've worked around this for now by hex-editing the DLL that contains this message, but... seriously. Is there an official way of getting rid of this message?
I'm prepared for a crappy stack trace from the problem thread(s).
Note that this is a security feature, so disable it at your own risk. There are two options:
If you know which module is causing this, you can add the full path to the register: HKLM\Software\Microsoft\Windows NT\CurrentVersion\KnownFunctionTableDlls registry key
You can disable it with .settings set EngineInitialization.VerifyFunctionTableCallbacks=false
The second option only disables it for the current session. If you want to make it permanent, you can follow it with .settings save.
if you are running the latest versions of windbg
you can try setting the Engine Initialization Settings
0:000> dx Debugger.Settings.EngineInitialization.VerifyFunctionTableCallbacks
Debugger.Settings.EngineInitialization.VerifyFunctionTableCallbacks : true
0:000> dx Debugger.Settings.EngineInitialization.VerifyFunctionTableCallbacks = false
Debugger.Settings.EngineInitialization.VerifyFunctionTableCallbacks = false : false
0:000> dx Debugger.Settings.EngineInitialization.VerifyFunctionTableCallbacks
Debugger.Settings.EngineInitialization.VerifyFunctionTableCallbacks : false
Related
I'm unable to figure out why WinDBG is in a BUSY state:
Is there a way to find a description?
There is no way to find the exact reason why WinDbg is busy, but you can verify what the last event it was responding to, by using '.lastevent'. However, for your particular case, it is busy looking for symbols and source code for kernel32!CreateFileW. If you have an extension registered for events you would receive change symbol state
IDebugEventCallbacksWide::ChangeSymbolState
DEBUG_CSS_LOADS The engine has loaded some module symbols.
DEBUG_CSS_UNLOADS The engine has unloaded some module symbols.
DEBUG_CSS_SCOPE The current symbol scope has changed.
DEBUG_CSS_PATHS The executable image, source , or symbol search paths have changed.
DEBUG_CSS_SYMBOL_OPTIONS The symbol options have changed.
DEBUG_CSS_TYPE_OPTIONS The type options have changed.
Also check this:
IDebugEventCallbacksWide::ChangeEngineState
Those events are:
DEBUG_CES_CURRENT_THREAD The current thread has changed, which implies that the current target and current process might also have changed.
DEBUG_CES_EFFECTIVE_PROCESSOR The effective processor has changed.
DEBUG_CES_BREAKPOINTS One or more breakpoints have changed.
DEBUG_CES_CODE_LEVEL The code interpretation level has changed.
DEBUG_CES_EXECUTION_STATUS The execution status has changed.
DEBUG_CES_ENGINE_OPTIONS The engine options have changed.
DEBUG_CES_LOG_FILE The log file has been opened or closed.
DEBUG_CES_RADIX The default radix has changed.
DEBUG_CES_EVENT_FILTERS The event filters have changed.
DEBUG_CES_PROCESS_OPTIONS The process options for the current process have changed.
DEBUG_CES_EXTENSIONS Extension DLLs have been loaded or unloaded. (For more information, see Loading Debugger Extension DLLs.)
DEBUG_CES_SYSTEMS A target has been added or removed.
DEBUG_CES_ASSEMBLY_OPTIONS The assemble options have changed.
DEBUG_CES_EXPRESSION_SYNTAX The default expression syntax has changed.
DEBUG_CES_TEXT_REPLACEMENTS Text replacements have changed.
I'm working on a vector layer where I have to merge all n+i [id] attributes into entity(n)[id] where entities(n+i)[id] equals the entity(n)[id], then delete all n+i entities.
All works fine but I call several times startEditing functions before commiting changes, and my question is: does calling commitChanges closes startEditing, or does it let it opened, like if it was a file descriptor or a pointer which we needed to free after the job's done?
The code is:
olayer.startEditing()
olayer.changeAttributeValue(n,id_obj,id_obj_sum,NULL,True)
olayer.commitChanges()
olayer.startEditing()
i= i-1
while i >=1:
olayer.deleteFeature(n+i)
i=i-1
olayer.commitChanges()
As you can see, we call several times olayer.startEditing, even more because all that code is in while body...
So will that spawn hordes of startEditing "pointers" or will it just continuously set the olayer editable status as "open to edition" ?
Actually the code works, but it's painfully slow, is this the reason why ?
By and large, you should not start the edit mode more than once in your layer.
You can commit at the end of all your changes to the layer, so that your modifications stay in an edit buffer in the meantime.
QgsVectorLayer.commitChanges() can let the edit mode open if you pass a False as parameter (the parameter is called stopEditing, see the docs). Like this:
# If the commit is sucessful, let the edit mode open
layer.commitChanges(False)
Also, have a look at the with edit(layer): syntax in the QGIS docs. Using such syntax you avoid starting/committing/closing the edit mode, QGIS does it for you.
with edit(layer):
# All my layer modifications here
# When this line is reached, my layer modifications are already committed.
I'm unable to understand how the mock-debugger extension controls where the next step is.
For example what if I'd like to step 2 lines if I find the word "banana" in my text? Also, I'd like to do something, like "Step In", where I can walk word-by-word - is it possible?
I've seen the this._currentLine = ln; assign, which looks like it controls where the line is, but it's just a simple local variable. How could it ever control anything in the debugger? I can't find any other uses of the _currentLine varbiable where it passes to anything useful API (except for stack tracing, but I don't think it has any relation with the debugger line-control).
The stack trace is the only source for the debugger step visualization. When the debugger gets a notification to pause it requests the current stack trace. The TOS determines where the next execution point will be located. Hence the debug adapter is reponsible to determine this position precisely.
I'm currently trying to find a way to automate the clearing of the trace window in CANoe.
I've had a look on the help menu within CANoe but there's nothing apart from a manual x option available on the Trace window itself. Does anyone have any ideas?
Syntax
void traceWindowClear(char[] windowName);
Function
Clears the contents of the Trace Window.
Parameters
windowName - The name of the Trace Window.
Return Values
—
Availability
Since Version 11.0 In Measurement Setup and Simulation / Test Setup.
How can I set all exceptions behavior to pass to application and not appear in debugger?
I'm using IDA Pro 6.6 and WinDbg.
It's a bit awkward to do that for all exception types at once
.foreach(exc {sx}) {.catch{sxd ${exc}}}
What it does:
{sx}: list all exception types (and current settings, which you actually don't want)
exc: assign a variable
.foreach(...) {...}: cut it into pieces of single words and execute a command
sxd ${exc}: disable whatever is in variable exc
.catch{...}: ignore all the error messages which come from the settings information
The advantage of the above approach is that it is WinDbg version independent. If new exception codes are introduced, it will still work.
Processing of unwanted text can be avoided with PyKd. Save the following script into a file sdx.py and run !py sxd.py:
from pykd import *
sx = dbgCommand("sx")
for s in sx.splitlines():
ex = s[:4]
if not ex=="" or ex.isspace():
print("sxd "+ex)
dbgCommand("sxd "+ex)
Another option is processing all the exceptions manually:
.foreach(exc {.echo "ct et cpr epr ld ud ser ibp iml out av asrt aph bpe bpec eh clr clrn cce cc dm dbce gp ii ip dz iov ch hc lsq isc 3c svh sse ssec sbo sov vs vcpp wkd rto rtt wob wos *"}) {.catch{sxd ${exc}}}
However, if there are new exception codes in WinDbg, you have to add them to the .echo command.
In Windbg the sx family of commands is used to control how
exceptions should be handled.
For passing an exception directly to the application, use the sxd command which disable a specific exception.
(Actually disable mean ignore first chance exception)
To my knowledge, you must use sxd on all specific exceptions,
because sxd * means all exceptions that are not otherwise explicitly named.
Use the sx command to see the available exceptions and current settings. And use sxd on all you want to disable.
0:000> sx
ct - Create thread - ignore
et - Exit thread - ignore
cpr - Create process - ignore
<cut>
av - Access violation - break - not handled
0:000> sxd av
0:000> sx
ct - Create thread - ignore
et - Exit thread - ignore
<cut>
av - Access violation - second-chance break - not handled
The output is in my opinion a bit difficult to interpret; the av (access violation) will now not be handled by the debugger in any visible way.
The “Controlling Exceptions and Events” section in the help explains
the first chance and second-chance concept.
You can optionally control this from the WinDbg GUI 'Debug>Event Filters...' this will open a dialog box like so:
Here you can set how WinDbg handles each exception type and whether they should be enabled, disabled, outputted to the WinDbg console output or ignored and then on the event firing whether WinDbg or your app should handle it.
So in your case you can select 'Ignore' and 'Not Handled' there a MSDN page that explains a little more: https://msdn.microsoft.com/en-us/library/windows/hardware/ff541752(v=vs.85).aspx