Programmatic Breakpoint IDs
Breakpoint Syntax (learn.microsoft.com) claims this about setting breakpoints using an expression for the ID.
Breakpoint IDs do not have to be referred to explicitly. Instead, you
can use a numerical expression that resolves to an integer that
corresponds to a breakpoint ID. To indicate that the expression should
be interpreted as a breakpoint, use the following syntax.
b?[Expression]
In this syntax, the square brackets are required, and Expression stands for any numerical expression that resolves to an integer that corresponds to a breakpoint ID.
This is exactly what I want to do. However, it doesn't seem to work for me.
The one example they give
b?[#$t0]
produces a syntax error. I tried it a few other ways.
0:000> r $t0 = 300
0:000> ? $t0
Evaluate expression: 768 = 00000300
0:000> b?[#$t0]
^ Syntax error in 'b?[#$t0]'
0:000> b0
^ Syntax error in 'b0'
0:000> b
^ Syntax error in 'b'
0:000> bl?[#$t0]
^ Syntax error in 'bl?[#$t0]'
0:000> bl
0 e 77c27d89 0001 (0001) 0:**** ntdll!LdrpDoDebuggerBreak+0x2b
0:000> bl0
0 e 77c27d89 0001 (0001) 0:**** ntdll!LdrpDoDebuggerBreak+0x2b
0:000> bl300
0:000>
I don't really know if the example given is viable, since b and b0 don't work. However, I can't seem to use a similar syntax for commands that otherwise work with hardcoded values.
How can I make use of this (mythical?) feature?
(WinDbg 10.0.17134.12 X86)
The what is a regex substitute either of these (p,u,a) which will denote
bp1 .. bpn | ba1 ... ban | bu1 .. bun
0:000> bl
0 e 62e5f7a0 0001 (0001) xxx
1 e 62e5f7a2 0001 (0001) xxx
2 e 62e5f7a3 0001 (0001) xxx
3 e 62e5f7a5 0001 (0001) xxx
0:000> bp[8-5]
breakpoint 3 exists, redefining
breakpoint 0 redefined
0:000>
or a better usage scenerio
0:000> bp .
0:000> bl
0 e 77ac05a6 0001 (0001) 0:**** ntdll!LdrpDoDebuggerBreak+0x2c
0:000> r $t0 =0
0:000> bp[#$t0] ntdll!LdrpCompareServiceChecksum
breakpoint 0 exists, redefining
0:000> bl
0 e 77a4b931 0001 (0001) 0:**** ntdll!LdrpCompareServiceChecksum
0:000> bp[#$t0] kernel32!CreateWaitableTimerExA
breakpoint 0 exists, redefining
0:000> bl
0 e 77584202 0001 (0001) 0:**** kernel32!CreateWaitableTimerExA
0:000>
Related
I want to define a shortcut using autohotkey that automates navigation to the Cell Width text box in Word's ribbon menu (i.e. sends the keys Alt,j,l,w while in Word).
My initial attempt at a script introduces an issue where the Up actions of the physical key presses haven't completed before the keys are sent by the script, causing it to fail.
Although I have a workaround (using sleep 250, shown further below), I would like to understand whether there is a more elegant solution - e.g. this value was chosen by trial and error, and this workaround may fail on a different machine, or if my laptop is having a bad day.
Essentially, I would like to find a solution that avoids hardcoding a wait duration.
Any suggestions?
The issue
In my initial script I tried to define the hotkey Alt+Shift+p in Word, to send Alt,j,l,w in sequence. This fails and enters the text "jlw" into the active table cell instead.
This is because for keys physically pressed (marked with # in comments below), the Up actions are yet to run when the script has already begun sending keys (indicated with $). This disrupts the send sequence Alt,j,l,w so it fails.
Also note events marked with ? may be a byproduct of the failed actions.
Script
; Jump to table cell width entry when Alt+Shift+p pressed in Word only
#IfWinActive, ahk_exe WINWORD.EXE
!+p::
Send, {RAlt down}{RAlt up}jlw
Return
Key history
VK SC Type Up/Dn Elapsed Key Comment
-------------------------------------------------------------------------------------------------------------
A4 038 d 1.03 LAlt #
A0 02A d 0.14 LShift #
50 019 h d 0.13 p #, h=Hook Hotkey
A5 138 i d 0.02 RAlt $
A5 138 i u 0.00 RAlt $
11 01D i d 0.00 Control ?
11 01D i u 0.00 Control ?
A4 038 i u 0.00 LAlt #
A0 02A i u 0.00 LShift #
4A 024 i d 0.00 j $
4A 024 i u 0.00 j $
4C 026 i d 0.00 l $
4C 026 i u 0.00 l $
57 011 i d 0.00 w $
57 011 i u 0.00 w $
11 01D i d 0.00 Control ?
A4 038 i d 0.00 LAlt ?
11 01D i u 0.00 Control ?
A0 02A i d 0.00 LShift ?
50 019 s u 0.08 p #
A0 02A u 0.25 LShift ?
A4 038 u 0.00 LAlt ?
Workaround
By adding a sleep 250 statement, the hotkey and sent keys run in the intended sequence. Note no other keys are triggered (nothing indicated with ?).
Script
; Jump to table cell width entry when Alt+Shift+p pressed in Word only
#IfWinActive, ahk_exe WINWORD.EXE
!+p::
Sleep 250
Send, {RAlt down}{RAlt up}jlw
Return
Key history
VK SC Type Up/Dn Elapsed Key Comment
-------------------------------------------------------------------------------------------------------------
A4 038 d 0.39 LAlt #
A0 02A d 0.20 LShift #
50 019 h d 0.20 p #, h=Hook Hotkey
50 019 s u 0.11 p #
A0 02A u 0.11 LShift #
A4 038 u 0.00 LAlt #
A5 138 i d 0.03 RAlt $
A5 138 i u 0.00 RAlt $
4A 024 i d 0.00 j $
4A 024 i u 0.00 j $
4C 026 i d 0.00 l $
4C 026 i u 0.00 l $
57 011 i d 0.00 w $
57 011 i u 0.00 w $, SUCCESS!
If the target window does not receive the keystrokes reliably, you can try increasing the press duration in the send command via the second parameter of SetKeyDelay, eg.
!+p::
SetKeyDelay, 10, 10
Send, {RAlt down}{RAlt up}jlw
Return
Not sure why you're using right alt, don't think that's supposed to work even. Just use "Alt". And I think your hotkey is not very good for this. Word gets confused with the input.
But I think maybe doing this, could work
!+p up:: ;up means it'll run once u release p, might help a bit
SetKeyDelay, 500, 10 ;good amount of delay, can probably do with less
Send, {Shift Up}{Alt Up}{Alt}jlw ;send shift and alt up first
Return
And now for a better alternative option, automating it with the Word ComObject. Usage of VBA for this is the normal and intended way, but you can AHK (or any other language) just as well.
Here's a quick AHK example of changing the first table's first cell's width:
Word := ComObjActive("Word.Application")
Word.ActiveDocument.Tables(1).Cell(1, 1).Width := 500
Of course that's not a very good way to go about this, I'm sure you can reference the active table and active cell somehow, I just quickly read the docs and wrote that. Haven't actually ever used any of this stuff in practice myself.
I found a more elegant solution using KeyWait. Compared to my earlier workaround script, I consider this more elegant since it doesn't require hardcoding a wait duration. This simply waits for the pressed keys to come up before the script continues, preventing any conflict:
Script
#IfWinActive, ahk_exe WINWORD.EXE
!+p::
KeyWait Alt
KeyWait Shift
KeyWait p
Send, {Alt Down}{Alt Up}jlw
Return
Key history
VK SC Type Up/Dn Elapsed Key Comment using previous notation
-------------------------------------------------------------------------------------------------------------
A4 038 d 0.63 LAlt #
A0 02A d 0.11 LShift #
50 019 h d 0.11 p #
50 019 s u 0.06 p #
A0 02A u 0.19 LShift #
A4 038 u 0.00 LAlt #
12 038 i d 0.01 Alt $
12 038 i u 0.00 Alt $
4A 024 i d 0.00 j $
4A 024 i u 0.00 j $
4C 026 i d 0.00 l $
4C 026 i u 0.00 l $
57 011 i d 0.00 w $
57 011 i u 0.00 w $
Interestingly, the above script modified to use Send, !jlw works (i.e. navigates to the Cell Width box) but the sent keys come Up out of sequence as follows. I won't use this, just to avoid any unintended consequences of this occurring out of sequence.
VK SC Type Up/Dn Elapsed Key Comment
-------------------------------------------------------------------------------------------------------------
A4 038 d 1.17 LAlt
A0 02A d 0.11 LShift
50 019 h d 0.14 p
50 019 s u 0.09 p
A0 02A u 0.16 LShift
A4 038 u 0.00 LAlt
A4 038 i d 0.02 LAlt <--
4A 024 i d 0.00 j
4A 024 i u 0.00 j
A4 038 i u 0.00 LAlt <--
4C 026 i d 0.00 l
4C 026 i u 0.00 l
57 011 i d 0.00 w
57 011 i u 0.00 w
Most of the keys work in combination with AltGr+Alt+[key]. The not working exceptions I found are y and . (period). I am following this instruction (https://www.autohotkey.com/docs/KeyList.htm#SpecialKeys Step 1 to 5) in order to analyze the problem.
Log output for AltGr+Alt+x (my AHK script is working with that shortcut)
A2 01D d 11.34 LControl
A5 138 d 0.00 RAlt
A4 038 d 0.13 LAlt
58 02D d 0.20 x
58 02D u 0.13 x
A2 01D u 0.17 LControl
A5 138 u 0.00 RAlt
A4 038 u 0.00 LAlt
Log output for AltGr+Alt+y (my AHK script is NOT working with that short cut)
A2 01D d 1.89 LControl
A5 138 d 0.00 RAlt
A4 038 d 0.05 LAlt
A2 01D u 0.36 LControl
A5 138 u 0.00 RAlt
A4 038 u 0.06 LAlt
This log output leads me to believe, that the problem is not my script, but something more global. It seems that AHK is not even receiving the key stroke for "y".
Log output for AltGr+y to prove that my keyboard isn't defective :)
A2 01D d 10.27 LControl
A5 138 d 0.00 RAlt
59 02C d 0.23 y
59 02C u 0.13 y
A2 01D u 0.17 LControl
A5 138 u 0.00 RAlt
Can any of you reproduce this? How can I use AltGr+Alt+Y as a shortcut?
I am using Win10 x64 and AHK Version 1.1.30.01.
Edit
Obviously, the issue is only on my computer. So I would like to change the question slightly into: How can I identify and eliminate the reason that blocks some hotkeys? Remember that AltGr+Alt+Y is not the only hotkey that does not work, also AltGr+Alt+. and AltGr+Alt+O and possibly more that I have not tested yet.
Instead of AltGr+LAlt+Key or AltGr+RControl+Key which may cause issues in some programs or key jamming, you can use any other key in place of LAlt or RControl this way:
LControl & RAlt:: AltGr := true ; assign the boolean value "true" to the variable 'AltGr''
LControl & RAlt Up:: AltGr := false
; The #If directive creates context-sensitive hotkeys and hotstrings
#If (AltGr) ; If this variable has the value "true"
a:: MsgBox AltGr+a
a & b:: MsgBox AltGr+a+b
b & a:: MsgBox AltGr+b+a
h & l:: Send Hello
i & e:: Run iexplore.exe
n & p:: Run notepad
w & p:: Run wordpad
#If ; turn off context sensitivity
https://autohotkey.com/docs/commands/_If.htm
Please, observe:
0:033> .echo 5+5
5+5
0:033> ? 5+5
Evaluate expression: 10 = 00000000`0000000a
0:033> r #$t0=5+5
0:033> r #$t0
$t0=000000000000000a
0:033> .echo #$t0
#$t0
? is almost what I need, but it is too verbose. Is there a way to invoke .echo on an expression, so that it display the result of the expression and not the expression text?
i use a script file like this when i need a plain output
the semicolon is needed or a blank line is needed in the script file
setting alias cant be the first command in script file
edit using alias
When a line begins with an as command, aliases and tokens in that line
are not expanded. If we put a semicolon or blank space before the as
command, then any alias or token that already has a value is expanded.
;aS /x temp ${$arg1} ${$arg2} ${$arg3}
.block
{
.echo ${temp}
}
ad *
and use it like this
0:000> $$>a< eval.txt 5 + 5
0xa
0:000> $$>a< eval.txt f + f
0x1e
0:000> $$>a< eval.txt f + 8
0x17
0:000> $$>a< eval.txt 0n16 + 0n16
0x20
0:000> $$>a< eval.txt 0x10 + 0x10
0x20
0:000> $$>a< eval.txt 0x10 * 0x10
0x100
0:000> $$>a< eval.txt 0n10 * 0n10
0x64
0:000> $$>a< eval.txt 5 << 3
0x28
0:000> $$>a< eval.txt 5 >> 3
0x0
0:000> $$>a< eval.txt f >> 3
0x1
0:000> $$>a< eval.txt 0y101 + 0y111
0xc
0:000> $$>a< eval.txt 0y101 % 0y111
0x5
0:000> $$>a< eval.txt 0y111 % 2
0x1
0:000> $$>a< eval.txt 0y111 % 4
0x3
0:000> $$>a< eval.txt 0y111 % 0n10
0x7
0:000> $$>a< eval.txt 0y111 / 0n10
0x0
0:000> $$>a< eval.txt 0n2 / 0n10
0x0
0:000> $$>a< eval.txt ##c++(#$teb->ProcessEnvironmentBlock) + 18
0x7ffd6018
0:000> $$>a< eval.txt 5 & 1
0x1
0:000> $$>a< eval.txt 5 & 2
0x0
0:000> $$>a< eval.txt 5 & 3
0x1
0:000> $$>a< eval.txt 5 & 4
0x4
0:000> $$>a< eval.txt 5 & 5
0x5
0:000> $$>a< eval.txt #esp & #esp
0x12f9a4
0:000> $$>a< eval.txt 3 | 4
0x7
0:000> $$>a< eval.txt poi(#esp+c) + 0
0x7ffd6000
0:000> $$>a< eval.txt poi(#esp+c) + #ecx
0x80105988
0:000> $$>a< eval.txt #ecx + 0
0x12f988
0:000> $$>a< eval.txt calc + 3c
0x1d003c
0:000> $$>a< eval.txt poi(calc+3c) + calc
0x1d00d8
.printf may do the job straight away:
0:000> .printf "%d", 5+5
10
Of course you can also hack around .echo to get it in decimal or even hex:
0:000> .foreach /pS 2 /ps 2 (word {? 5+5}) { .echo ${word}}
10
0:000> .foreach /pS 4 (word {? 5+5}) { .echo ${word}}
0000000a
The C++ expression evaluation (??) output is related, but has type information
0:000> ?? 5+5
int 0n10
I set the following breakpoint:
bp MSPTLS!LsCreateLine 100
The program crashes before the break point is hit 100 times. When I do bl after the crash, I get the following:
0 e 5dca4b62 0072 (0100) 0:**** MSPTLS!LsCreateLine
I am assuming from this information that the break point was hit 72 times before the crash.
However, when I do bp MSPTLS!LsCreateLine 80 I am able to hit the breakpoint before the crash telling me that the break point was hit more than 72 times before the crash. Does this 72 not indicate how many times the break point was hit?
The default number format of WinDbg is hexadecimal. If you want decimal numbers, prefix them with 0n:
0:005> bp ntdll!DbgBreakPoint 0n100
0:005> bl
0 e 7735000c 0064 (0064) 0:**** ntdll!DbgBreakPoint
The counter 0064 before (0064) counts backwards. You can easily observe that in any GUI application:
0:000> bl
0 e 74fd78d7 000a (000a) 0:**** USER32!NtUserGetMessage+0x15
1 e 74fd78c2 0064 (0064) 0:**** USER32!NtUserGetMessage
0:000> g
Breakpoint 0 hit
eax=00000001 ebx=00000001 ecx=00000000 edx=00000000 esi=001faf8c edi=74fd787b
eip=74fd78d7 esp=001faf44 ebp=001faf60 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
USER32!NtUserGetMessage+0x15:
74fd78d7 83c404 add esp,4
0:000> bl
0 e 74fd78d7 0001 (000a) 0:**** USER32!NtUserGetMessage+0x15
1 e 74fd78c2 005a (0064) 0:**** USER32!NtUserGetMessage
0:000> ? 5a
Evaluate expression: 90 = 0000005a
In the example, breakpoint 0 has been hit 10 times, leaving breakpoint 1 at 90.
I have two Raspberry Pis running python code to retrieve the serial number of an RFID tag. One has an RFID reader with a Wiegand interface hooked to GPIO pins and other has an RFID reader that behaves like a keyboard connected over USB. However, I get different numbers from the two reader when scanning the same RFID tag.
For example, for one tag, I get 57924897 from the Raspberry Pi with the Wiegand reader and 0004591983 from the Raspberry Pi with the USB keyboard reader.
Can sombody explain the difference? Are both readers reading the same? Or are they just reading some different parameter?
Looking at those two values, it seems that you do not properly read and convert the value from the Wiegand interface.
The USB keyboard reader reads the serial number in 10 digit decimal form. A Wiegand reader typically trunkaes the serial number into a 26 bit value (1 parity bit + 8 bit site code + 16 bit tag ID + 1 parity bit).
So let's look at the two values that you get:
+--------------+------------+-------------+-----------------------------------------+
| READER | DECIMAL | HEXADECIMAL | BINARY |
+--------------+------------+-------------+-----------------------------------------+
| USB keyboard | 0004591983 | 0046116F | 0000 0000 0100 0110 0001 0001 0110 1111 |
| Wiegand | 57924897 | 373DD21 | 1 1011 1001 1110 1110 1001 0000 1 |
+--------------+------------+-------------+-----------------------------------------+
When you take a close look at the binary representation of those two values, you will see that they correlate with each other:
USB keyboard: 0000 0000 0100 0110 0001 0001 0110 1111
Wiegand: 1 1011 1001 1110 1110 1001 0000 1
So it seems as if the Wiegand value matches the inverted value obtained from the USB keyboard reader:
USB keyboard: 0000 0000 0100 0110 0001 0001 0110 1111
NOT(Wiegand): 0 0100 0110 0001 0001 0110 1111 0
So the inverted value (logical NOT) from the Wiegand interface matches the value read by the USB reader.
Next, let's look at the two parity bits. The data over the Wiegand interface typically looks like:
b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11 b12 b13 b14 b15 b16 b17 b18 b19 b20 b21 b22 b23 b24 b25
PE D23 D22 D21 D20 D19 D18 D17 D16 D15 D14 D13 D12 D11 D10 D9 D8 D7 D6 D5 D4 D3 D2 D1 D0 PO
The first line being the bits numbered as they arrive over the Wiegand wires. The second line being the same bits as they need to be interpreted by the receiver, where PE (b0) is an even parity bit over D23..D12 (b1..b12), PO (b25) is an odd parity bit over D11..D0 (b13..b24), and D23..D0 are the data bits representing an unsigned integer number.
So looking at your number, you would have received:
PE D23 D22 D21 D20 D19 D18 D17 D16 D15 D14 D13 D12 D11 D10 D9 D8 D7 D6 D5 D4 D3 D2 D1 D0 PO
0 0 1 0 0 0 1 1 0 0 0 0 1 0 0 0 1 0 1 1 0 1 1 1 1 0
If we check the parity bits PE and PO, we get:
PE D23........D12
0 0100 0110 0001
contains 4 ones (1), hence even parity is met.
D21.........D0 PO
0001 0110 1111 0
contains 7 ones (1), hence odd parity is met.
So, to summarize the above, your code reading from the Wiegand interface does not properly handle the Wiegand data format. First, it does not trim the parity bits and second, it reads the bits with wrong polarity (zeros are ones and ones are zeros).
In order to get the correct number from the Wiegand reader, you either have to fix you code for reading from the Wiegand interface (to fix polarity, to skip the first and the last bit from the data value, and to possibly check the parity bits). Or you can take the value that you currently get, invert that value, and strip the lower and upper bits. In C, that would look something like this:
int unsigned currentWiegandValue = ...;
int unsigned newWiegandValue = ((~currentWiegandValue) >> 1) & 0x0FFFFFF;