I've been playing with the SetupApi on Windows 2003 over the last couple of days, and I'm seeing a bunch of errors I'm not expecting. For example, if I pass GUID_NULL to SetupDiGetClassDescription, it returns FALSE and GetLastError() returns 0xE0000206.
The GUID_NULL came from SetupDiEnumDeviceInfo; I'm not doing this deliberately.
I've also seen error 0xE0000209. Where are these "0xE" error values declared, defined or documented?
It turns out that they're in SetupAPI.h, but disguised.
0xE0000206 is ERROR_INVALID_CLASS:
#define ERROR_INVALID_CLASS (APPLICATION_ERROR_MASK|ERROR_SEVERITY_ERROR|0x206)
...and 0xE0000209 is ERROR_INVALID_REG_PROPERTY:
#define ERROR_INVALID_REG_PROPERTY (APPLICATION_ERROR_MASK|ERROR_SEVERITY_ERROR|0x209)
(and, in WinNT.h)...
#define APPLICATION_ERROR_MASK 0x20000000
#define ERROR_SEVERITY_ERROR 0xC0000000
0xC | 0x2 is 0xE.
Related
I need to get the address of the function required by .fnret command in WinDBG.
For example, I want to get the information about return value of apphelp!ApphelpCheckRunApp function.
First, I set a breakpoint on this function:
bp apphelp!ApphelpCheckRunApp
Then I'm continuing the execution, until it breaks on that function.
After breaking, I'm executing .fnret [Address] command.
I already tried to use the 77b345d5 address displayed on the breakpoint:
Breakpoint 0 hit
eax=77b345d5 ebx=7ed320f5 ecx=7ffac000 edx=7c886920 esi=7ffac000 edi=00000018
eip=77b345d5 esp=0378ce90 ebp=0378d108 iopl=0 nv up ei pl nz ac po cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000213
appHelp!ApphelpCheckRunApp:
77b345d5 8bff mov edi,edi
but that seems to be not what I need, because I get the following error:
^ Unknown or unsupported return type in '.fnret 77b345d5'
Also I used return address 7c818cdf of this function from call stack (got via kb command):
ChildEBP RetAddr Args to Child
0283ce8c 7c818cdf 00000474 046bb7d0 00000000 appHelp!ApphelpCheckRunApp
but it leads me to the same error.
Which WinDBG command I should use for that and which return address it will display (in case it isn't displayed yet on breakpoint)? Will it then properly work for .fnret or .fnret /s commands? Unfortunately, there are no any examples of using them on MSDN, only the documentation.
Hoping on your help. Thanks in advance.
.fnret is only useful if you have private pdb
it is not useful if you have public pdb because it needs to retrieve the type information
here is a sample usage on a compiled code with private pdb
0:000> x /t /v /f myst!towlower
prv func 00007ff6`74ba5f84 7 <function> myst!towlower (unsigned short)
0:000> x /t /v /f myst!toupper
prv func 00007ff6`74b91b10 2a <function> myst!toupper (int)
0:000> .fnret myst!towlower
myst!towlower (00007ff6`74ba5f84) = unsigned short 1
0:000> .fnret myst!toupper
myst!toupper (00007ff6`74b91b10) = int 0n1
error on a known function which returns a HANDLE using public stripped pdb
0:000> .fnret KERNELBASE!CreateFileA
^ Unknown or unsupported return type in '.fnret KERNELBASE!CreateFileA'
success on a system file with private pdb
it casts the forced return value dumped in #rax as a typed return with value of a function with type information
a system file with prrivate pdb
0:000> .printf "%y\n" , 0x00000001`800bace0 ; an arbitrary function
ole32!ToUnicode (00000001`800bace0)
0:000> .printf "%mu\n" , 00000001`8014c17a ; an arbitrary wide string
guageErrorPointerą“Š
0:000> r rax = 00000001`8014c17a the $retreg is populated with an address of wide string
0:000> .fnret 0x00000001`800bace0 << fnret casts the $retreg as wide string and prints the resulting widestring
ole32!ToUnicode (00000001`800bace0) = wchar_t * 0x00000001`8014c17a
"guageErrorPointer???"
OK, that command is indeed not helpful at all when using public PDBs.
I found better solution here: How to get return value from a function in windbg?.
It is possible to get the memory address of return value by viewing eax/rax register on x86/x64 appropriately, using r command (since it always is stored there). After breakpoint, I'm just typing r eax on x86 or r rax on x64. Output will be look like this:
eax=[Address]
Then, I'm displaying a value of received memory address via d* (dd, du etc. displaying data types commands), like this:
du [Address]
After looking at the output, it becomes understandable which data is returned, and its data type also (at least in most of cases).
But to understand first, which data type is used, I'm trying the different combinations of display memory commands and display referenced memory commands.
I need to distinguish the three forms:
#define CONSTANTNAME
#define CONSTANTNAME 0
#define CONSTANTNAME 1
I saw someone use the hint:
#if (CONSTANTNAME - 0)
but this confuse the form without value and the one with 0.
Is there something smarter?
Can I assume you want the empty definition and the 1 definition to be equivalent with the 0 is the different one? I'm pretty sure that question already exists on stackoverflow, but I can't find it.
Here's a usenet thread on the same topic: https://groups.google.com/d/msg/comp.lang.c/jkI2vz8ZxmE/1-kOKCQ2MrwJ
Several answers are given there. The cleverest one looks like:
#if -CONSTANTNAME+1 == 1
... the "no CONSTANTNAME" branch
#else
... the "yes CONSTANTNAME" branch
#endif
If CONSTANTNAME is empty, -+1 == 1 => false.
If it's 1, -1+1 == 1 => false.
If it's 0, -0+1 == 1 => true.
If it's not defined, the default cpp replacement for unrecognized tokens applies, and that's a 0 so it's true.
UPDATE
If you want 3 branches, you can still use the -FOO+0 == 1 test and add an extra test like FOO+0==0. Look at the results you can get:
Value of `FOO` `-FOO+1==1` `FOO+0==0`
empty string false true
1 false false
0 true true
If the 4th case, macro not defined, is interesting, it must be tested with #ifdef FOO or defined(FOO) since it is otherwise indistinguishable from 0.
Sample code:
#if !defined(FOO)
... handle undef
#elif -FOO+1 == 1
... handle 0
#elif FOO+0 == 0
... handle empty
#else
... handle 1
#endif
Suppose I have some macro #define NAME name, and I want to define some other macro which will expand to the quoted value. That is, as if I had also defined #define NAME_STR "name". Is there a neater way than the following?
#define QUOT(str) #str
#define QUOT_ARG(str) QUOT(str)
#define NAME_STR QUOT_ARG(NAME)
Not really, due to the fact that macro arguments are not expanded when used in stringification. From the GNU C PreProcessor manual:
Unlike normal parameter replacement,
the argument is not macro-expanded
first. This is called stringification.
From the same source:
If you want to stringify the result of
expansion of a macro argument, you
have to use two levels of macros.
...which continues with an example:
#define xstr(s) str(s)
#define str(s) #s
#define foo 4
str (foo)
==> "foo"
xstr (foo)
==> xstr (4)
==> str (4)
==> "4"
I am developing an application where i need to define several constants that will be used in more than one class.I have defined all my constants in one .h file(say "constants.h") and imported that file in myAppName_Prefix.pch file located in "Other sources" folder of the project.The classes using these constants are being compiled with out any error but other classes, where i declared some UISwipeGestureRecognizers, are throwing error as"Expected identifier before numeric constant"
this is the snippet of code from one of the classes that is showing error:
if (gesture.direction==UISwipeGestureRecognizerDirectionLeft)
i defined my constants as:
#define heading 1
#define direction 2
#define statement 3
#define refLink 4
#define correctResponse 5
#define incorrect1Response 6
if i define them in each class individually then everything as working fine.
Can any one please suggest me a way how to solve this issue.
After preprocessing your code
if (gesture.direction==UISwipeGestureRecognizerDirectionLeft)
looks like this
if (gesture. 2==UISwipeGestureRecognizerDirectionLeft)
and this is obviously not valid code.
The solution is to put an unique namespace string in front of your #defines.
#define hariDirection 2
or
#define kDirection 2
Or imho the best solution: don't use #define
typedef enum {
heading = 1,
direction,
statement,
refLink,
correctResponse,
incorrect1Response,
} MyDirection;
This will do the same thing, but it won't clash with other method and variable names.
I was getting the same error message from gcc.
error: expected ')' before numeric constant
#define UNIQUE_NAME 0
After checking that my variable names were unique, I realised that I had a typo at the point in the code where the constant was being used.
#define UNIQUE_NAME 0
//...
if (test_variable UNIQUE_NAME) { //missing ==
//...
}
simple mistake, but tricky to find because gcc was pointing me towards the #define statement
Make your constants names to be unique:
#define kHeading 1
#define kDirection 2
#define kStatement 3
#define kRefLink 4
#define kCorrectResponse 5
#define kIncorrect1Response 6
There are different kind of macros in the C language, nested macro is one of them.
Considering a program with the following macro
#define HYPE(x,y) (SQUR(x)+SQUR(y))
#define SQUR(x) (x*x)
Using this we can successfully compile to get the result.
As we all know the C preprocessor replaces all the occurrence of the identifiers with the replacement-string. Considering the above example I would like to know how many times the C preprocessor traverses the program to replace the macro with the replacement values. I assume it cannot be done in one go.
the replacement takes place, when "HYPE" is actually used. it is not expanded when the #define statement occurs.
eg:
1 #define FOO 1
2
3 void foo() {
4 printf("%d\n", FOO);
5 }
so the replacement takes place in line 5, and not in line 1. hence the answer to your question is: once.
A #define'd macro invocation is expanded until there are no more terms to expand, except it doesn't recurse. For example:
#define TIMES *
#define factorial(n) ((n) == 0 ? 1 : (n) TIMES factorial((n)-1))
// Doesn't actually work, don't use.
Suppose you say factorial(2). It will expand to ((2) == 0 ? 1 : (2) * factorial((2)-1)). Note that factorial is expanded, then TIMES is also expanded, but factorial isn't expanded again afterwards, as that would be recursion.
However, note that nesting (arguably a different type of "recursion") is in fact expanded multiple times in the same expression:
#define ADD(a,b) ((a)+(b))
....
ADD(ADD(1,2),ADD(3,4)) // expands to ((((1)+(2)))+(((3)+(4))))