Often times NOP is used to align instruction addresses. This is usually encountered for example when writing Shellcode to exploit buffer overflow or format string vulnerability.

Say you have a relative jump to 100 bytes forwards, and make some modifications to the code. The chances are that your modifications mess up the jump target’s address and as such you’d have to also change the aforementioned relative jump. Here, you can add NOPs to push the target address forward. If you have multiple NOPs between the target address and the jump instruction, you can remove the NOPs to pull the target address backward.

This would not be a problem if you are working with an assembler which supports labels. You can simply do JXX someLabel(where JXX is some conditional jump) and the assembler will replace the someLabel with the address of that label. However, if you simply modify the assembled machine code(the actual opcodes) by hand(as it sometimes happens with writing shellcode), you also have to change the jump instruction manually. Either you modify it, or then move the target code address by using NOPs.

Another use-case for NOP instruction would be something called a NOP sled. In essence the idea is to create a large enough array of instructions which cause no side-effects(such as NOP or incrementing and then decrementing a register) but increase the instruction pointer. This is useful for example when one wants to jump to a certain piece of code which address isn’t known. The trick is to place the said NOP sled in front of the target code and then jumping somewhere to the said sled. What happens is that the execution continues hopefully from the array which has no side-effects and it traverses forwards instruction-per-instruction until it hits the desired piece of code. This technique is commonly used in aforementioned buffer overflow exploits and especially to counter security measures such as ASLR.

Yet another particular use for the NOP instruction is when one is modifying code of some program. For example, you can replace parts of conditional jumps with NOPs and as such circumvent the condition. This is a often used method when “cracking” copy protection of software. At simplest it’s just about removing the assembly code construct for if(genuineCopy) ... line of code and replacing the instructions with NOPs and.. Voilà! No checks are made and non-genuine copy works!

Note that in essence both examples of shellcode and cracking do the same; modify existing code without updating the relative addresses of operations which rely on relative addressing.

A nop may be used in a a delay slot when no other instruction may be reordered to be placed in there.

lw   v0,4(v1)
jr   v0

In MIPS, this would be a bug because at the time the jr was reading the register v0 the register v0 hasn’t been loaded with the value yet from the previous instruction.

The way to fix this would be:

lw   v0,4(v1)
nop
jr   v0
nop

This fills the dealy slots after the load word and jump register instructions with a nop so that the load word instruction is completed before the jump register command is executed.

Further reading – a bit on SPARC filling of delay slots. From that document:

What can be put into the delay slot?

• Some useful instruction that should be executed whether you branch or not.
• Some instruction that does useful work only when you branch (or when you don’t branch), but doesn’t do any harm if executed in the
  other case.
• When all else fails, a NOP instruction

What MUST NOT be put into the delay slot?

• Anything that sets the CC that the branch decision depends on. The branch instruction makes the decision on whether to branch or not
  right away but it doesn’t actually do the branch until after the delay
  instruction. (Only the branch is delayed, not the decision.)
• Another branch instruction. (What happens if you do this is not even defined! The result is unpredictable!)
• A “set” instruction. This is really two instructions, not one, and only half of it will be in the delay slot. (The assembler will warn
  you about this.)

Note the third option in the what to put into the delay slot. The bug that you saw was likely someone filling one of the things that must not be put into the delay slot. Putting a nop in that location would then fix the bug.

Note: after re-reading the question, this was for x86, which doesn’t have delay slots (branching instead just stalls the pipeline). So that wouldn’t be the cause/solution to the bug. On RISC systems, that could have been the answer.

at least one reason to use NOP is alignment. x86 processors read data from main memory in quite big blocks, and start of block to read is always aligned, so if one has block of code, that will be read much, this block should be aligned. This will result in little speedup.

There is a x86 specific case still not described in other answers: interrupt handling. For some styles of it, there can be code sections when interrupts are disabled because the main code works with some data shared with interrupt handlers, but it’s reasonable to allow interrupts between such sections. If one naively writes

    STI
    CLI

this won’t process pending interrupts because, citing Intel:

After the IF flag is set, the processor begins responding to external, maskable interrupts after the next instruction is executed.

so this shall be rewritten at least as:

    STI
    NOP
    CLI

In the second variant, all pending interrupts will be processed just between NOP and CLI. (Of course, there can be many alternative variants, as doubling the STI instruction. But explicit NOP is more obvious, at least for me.)

One purpose for NOP (in general assembly, not only x86) it to introduce time delays. For example you want to program a microcontroller which has to output to some LEDs with a 1 s delay. This delay can be implemented with NOP (and branches). Of course you could use some ADD or something else, but that would make the code more unreadable; or maybe you need all the registers.

In general on the 80×86, NOP instructions are not required for program correctness, though occasionally on some machines a strategically-placed NOPs could cause code to run more quickly. On the 8086, for example, code would be fetched in two-byte chunks, and the processor had an internal “prefetch” buffer which could hold three such chunks. Some instructions would execute faster than they could be fetched, while other instructions would take awhile to execute. During slow instructions, the processor would attempt to fill the prefetch buffer, so that if the next few instructions were fast they could be executed quickly. If the instruction following the slow instruction starts on an even word boundary, the next six bytes worth of instructions will be prefetched; if it starts on an odd byte boundary, only five bytes will be prefetched. If I recall, a NOP took three cycles and a memory fetch took four, so if prefetching the extra byte would save a memory cycle, adding a “NOP” to cause the instruction after a slow one to start on an even word boundary could sometimes save a cycle.

Such memory alignment issues may affect program speed, but they won’t generally affect correctness. On the other hand, there are some prefetch-related issues on those older processors where a NOP could affect correctness. If an instruction alters a code byte which has already been prefetched, the 8086 (and I think the 80286 and 80386) will execute the prefetched instruction even though it no longer matches what’s in memory. Adding a NOP or two between the instruction that alters memory and the code byte which is altered may prevent the code byte from being fetched until after it has been written. Note, by the way, that many copy-protection schemes exploited this sort of behavior; note too, however, that this behavior is not guaranteed. Different processor variations may handle prefetch differently, some may invalidate prefetched bytes if the memory from which they were read is modified, and interrupts will generally invalidate the prefetch buffer; code will get re-fetched when the interrupts return.

NOP means No Operation

It is generally used for inserting or deleting machine code or to delay execution of a particular code.

Also used by crackers and debuggers to set breakpoints.

So probably doing something like :
XCHG BX, BX
will also result in the same.

Sound to me as if there were few operations which were still under process and hence it caused an error.

If you are familiar with VB, i can give you an example :

If you make a login system in vb, and load 3 pages together – facebook, youtube and twitter in 3 different tabs.

And use 1 login button for all.
It might give an error if your internet connection is slow. Which means one of the pages hasn’t loaded yet. So we put in Application.DoEvents to overcome this. Same way in assembly NOP can be used.