Problems List

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\

See also Jump submenu.

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:

• Convert to offset (DS)

• Convert to offset (CS)

• Convert to offset by any segment

• Convert to offset by any user-specified base

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

• or make the illegal address legal by creating a new segment.

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

1. The specified bytes do not form an instruction.

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

1. Enter the operand manually

2. or Create a new segment making the illegal address legal

3. or Change the current segment bounds using one of the following:

• How to change segment attributes

• How to move a 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 or

3. 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:

1. 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)

2. If you have found the offending function, change its attributes (namely, number of bytes purged upon return).

3. 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.