Description:
The current item has an operand marked as an offset,
but IDA cannot find the offset base in the database.
Possible reason(s):
The database is probably corrupted.
This may occur if the database was corrupted and repaired.
What to do: Mark the operand again as an offset. Use one of the following commands:
Description: Two reasons can cause this problem: 1.Reference to an illegal address is made in the program being disassembled; 2.IDA couldn't find a name for the address but it must exist. What to do:
If this problem is caused by a reference to an illegal address
or make the illegal address legal by creating a new segment.
Otherwise, the database is corrupt.
Problem: Cannot find alternative string for an operand
Description:
The current item has an operand marked as entered manually,
but IDA cannot find the manually entered string in the database.
Possible reason(s):
The database is corrupt.
What to do: Enter the operand manually again. Use one of the following commands: User-defined operand
Problem: Cannot find comment
Should not happen!
Please inform the author if you encounter this problem.
Problem: Cannot find references
Description:
The current item is marked as referenced from other place(s) in the
program, but IDA cannot find any reference to it.
Possible reason(s):
The database is corrupt.
What to do: Database is corrupt, the best thing to do is to reload the database.
Problem: Indirect execution flow
Description:
Actually, this is not a problem. IDA warns you
that here it encountered an indirect jump and
couldn't follow the execution.
What to do:
Nothing, this entry is just for your information
Problem: Cannot disassemble
Description:
IDA cannot represent the specified bytes as an instruction.
Possible reason(s):
The specified bytes do not form an instruction.
The current processor type is incorrect. What to do: If you are sure that the specified bytes contain an instruction, you can try to change processor type and mark these bytes as an instruction using the following command: Convert to instruction
Problem: Already data or code
Description: IDA cannot convert this byte(s) to an instruction or data because it would overlap another instruction. What to do: Make the following overlapping instruction or data 'unexplored' using undefine command.
Problem: Execution flows beyond limits
Description: IDA encountered a jump or call instruction to an illegal address. Namely:
jump/call beyond program segments
near jump/call beyond the current segment What to do:
Disable cross-references display or 4. Increase the limit in IDA.CFG, the parameter name is MAX_ITEM_LINES.
Problem: Failed to trace the value of the stack pointer
Description:
The value of the stack pointer at the end of the function is different
from its value at the start of the function. IDA checks for the
difference only if the function is ended by a "return" instruction.
The most probable cause is that stack tracing has failed.
This problem is displayed in the disassembly listing with
the "sp-analysis failed" comment.
What to do:
Examine the value of stack pointer at various locations of the function and try to find out why the stack tracing has failed. Usually, it fails because some called function changed the stack pointer (by purging the input parameters, for example)
If you have found the offending function, change its attributes (namely, number of bytes purged upon return).
Another way is to specify manually how the stack pointer is modified. See Change stack pointer command
Problem: Attention! Probably erroneous situation
Description:
This is a generic problem message. IDA uses it when no more detailed
information is available or the problem is processor-specific.
Problem: Decision to convert to instruction/data is made by IDA
Description:
In fact, this is not exactly a problem: IDA collects all the locations
where it has decided to convert undefined bytes to
instructions or data even if they don't have
any references to them. We consider this decision as dangerous
and therefore we provide you with a way to examine all such places.
What to do:
Examine the result of conversion and modify the instructions
or data if IDA has made a wrong conversion.
Problem: The decision made by IDA was wrong and rolled back
Description:
This problem occurs when IDA has converted unexplored bytes to
instruction(s) and later found that the decision was wrong.
For example:
mov ax, bx
db 0FFh, 0FFh
0FFh, 0FFh cannot be converted to an instruction, therefore
the "mov" instruction cannot be here.
In this case, IDA automatically destroys the instruction(s)
and enlists the address as problematic.
What to do:
Examine the end result and modify it accordingly.
FLIRT collision: the function with the given name already exists
Description:
It means that IDA recognized the function as coming
from a standard library but there already was another function
with the same name in the program.
What to do:
Examine the function and rename it as you wish.
FLIRT match indecision: reference to function expected
Description:
IDA matched code bytes against at least one
signature entry, but failed finding expected
cross-references at certain offsets in the code.
Consider the following .pat file contents:
5589E583EC18A1........890424E8........C9C3...................... 00 0000 0015 :0000 _test ^000F _my_fun0
5589E583EC18A1........890424E8........C9C3...................... 00 0000 0015 :0000 _smuk ^000F _my_fun1
Now, turn that .pat file into a signature (.sig) file, telling
sigmake to include function references into signature
(using the -r switch).
Then, apply that .sig file to a binary that you are
examining.
If IDA recognizes the 0x15-bytes long pattern in the binary, it
will check that, at offset 0xF from the start of the match,
a call to either "_my_fun0" or "_my_fun1" is performed.
If either one of the two is found, then that code will
be named "test", or "smuk", respectively.
Otherwise, a SIGFNREF problem will be signalled.
What to do:
Examine the code pointed to by the address at the given
offset (i.e., 0xF) and try and determine whether
that function could be "_my_fun0", or "_my_fun1".
If so, name it accordingly and re-apply the signature.
An alternative is to generate the signature (.sig)
file without the cross-references to functions
(i.e., dropping the '-r' switch).
But beware of collisions: a pattern like the
one above will inevitably create a collision, since the
pattern bytes are similar for the two entries.
