Sous de nombreux hôtes DPMI ,les interruptions restent toujours activées en mode protége (ex: le flag i reste posé )pour autoriser le multitâche preemptif . Ces hôtes maintiennent un état d'interruption virtuelle pour chaque machine virtuelle, détournant l'exécution des instructions qui ordinairement affectent le flag des interruptions matérielles et ajustant le flag d'interruption virtuelle du client . Quand le flag d'interruption virtuelle est effacé par une instruction CLI du client ou un appel à fonction DPMI Int 31H 0900H, le programme ne recoit plus aucune interruption matérielle jusqu'a ce qu'il repose le flag avec STI ou un appel àFonction 0901H. Les clients DPMI ne doivent pas utiliser l'instruction PUSHF pour examiner leur statut d'interruption. C'est parceque PUSHF sauve les flags réels du CPU sur la pile, ce qui ne reflète pas l'état du flag d'interruption virtuelle du client. De la même manière,les clients ne peuvent employer IRET(D) ou POPF pour modifier le flag d'interruption, car ces instructions accèdent au flag d'interruption physique et sont ignorées par le CPU à cause du niveau de privilege du client .
Exemple: Le code source demontre comment un client pourrait desactiver les interruptions virtuelles avant d'entrer dans une section de code critique ,puis restaurer le flag d'interruption virtuelle à son état précedent à la fin de la section critique:
mov ax,0900h ; lit le precedent flag virtuel int 31h ; et desactive les interruptions push ax ; sauve la valeur 0900H ou 0901H . . ; code critique . pop ax int 31h ; restaure precedent flag virtuelSi le client connait déjà (ou ne se soucie pas) l'état precedent du flag d'interruption virtuelle, il peut utiliser CLI et STI au lieu des fonctions DPMI 0900H et 0901H. Le programmeur doit assumer que l'execution de chacune de ces instructions sera ralenti.