## Keyboard shortcuts

Press `←` or `→` to navigate between chapters

Press `S` or `/` to search in the book

Press `?` to show this help

Press `Esc` to hide this help

# Problems list

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
- NOFORCED Cannot find alternative string for an operand
- NOCMT Cannot find comment
- NOREF Cannot find references
- INDIRJMP Indirect execution flow
- NODISASM Cannot disassemble
- ALREADY Already data or code
- BOUNDS Execution flows beyond limits
- OVERFLOW Too many lines
- BADSTACK Failed to trace the value of the stack pointer
- LOOKHERE Attention! Probably erroneous situation
- DECISION Decision to convert to instruction/data is made by IDA
- ROLLBACK The decision made by IDA was wrong and rolled back
- COLISION FLIRT collision: the function with the given name already exists
- SIGFNREF FLIRT match indecision: reference to function expected\

## 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:

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:

1. If this problem is caused by a reference to an illegal address:

- Try to enter the operand manually (The Manual… command; action `ManualOperand`), or
- Make the illegal address legal by creating a new segment (Create segment… command; action `CreateSegment`)

2. 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):

1. The specified bytes do not form an instruction.
2. 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:

1. Enter the operand manually (The Manual… command; action `ManualOperand`), or
2. Create a new segment making the illegal address legal (Create segment… command; action `CreateSegment`), or
3. Change 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:

1. If the current item is an array or string literal, try to divide it, or
2. Delete additional comment lines (added via Edit → Comments → Enter anterior/posterior lines…), or
3. Disable cross-references display (Options → General… → Cross-references), 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:

1. 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)
2. If you have found the offending function, change (Edit → Functions → Edit function…) its attributes (namely, number of bytes purged upon return).
3. 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:

                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.