Problems
These problems appear in the Problems window (View → Open subviews → Problems). IDA automatically detects and lists potential issues during analysis, helping you identify areas that may need manual review or correction.
The following problems may occur:
NOOFFSET Cannot find offset base
NONAME Cannot find name
NOCMT Cannot find comment
NOREF Cannot find references
INDIRJMP Indirect execution flow
NODISASM Cannot disassemble
ALREADY Already data or code
OVERFLOW Too many lines
Problem: Cannot find offset base
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:
Offset (data segment) (action
OpOffset)Offset (current segment) (action
OpOffsetCs)Offset by (any segment)... (action
OpAnyOffset)Offset (user-defined)... (action
OpUserOffset)
Problem: Cannot find name
Description: Two reasons can cause this problem:
Reference to an illegal address is made in the program being disassembled;
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:
Try to enter the operand manually (The Manual... command; action
ManualOperand), orMake the illegal address legal by creating a new segment (Create segment... command; action
CreateSegment)
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 the Manual... command (action ManualOperand).
Problem: Cannot find comment
Description: 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 (Options → General... → Analysis) is incorrect.
What to do: If you are sure that the specified bytes contain an instruction, you can try to change processor type (Options → General... → Analysis) and mark these bytes as an instruction using the following command: Code (action MakeCode)
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 the Undefine command (action MakeUnknown).
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:
Enter the operand manually (The Manual... command; action
ManualOperand), orCreate a new segment making the illegal address legal (Create segment... command; action
CreateSegment), orChange the current segment bounds using one of the following:
change segment attributes (Edit → Segments → Edit segment…)
move a segment (Edit → Segments → move current segment…)
Problem: Too many lines
Description: The current item (instruction or data) occupies more lines on the screen than it is allowed by the current configuration.
What to do:
If the current item is an array or string literal, try to divide it, or
Delete additional comment lines (added via Edit → Comments → Enter anterior/posterior lines...), or
Disable cross-references display (Options → General... → Cross-references), or
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 (Edit → Functions → Change 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 (Edit → Functions → Edit function…) its attributes (namely, number of bytes purged upon return).
Another way is to specify manually how the stack pointer is modified. See the Edit → Functions → 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:
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:
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.
Last updated
Was this helpful?