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'éxecution 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 avecSTI ou un appel àFonction 0901H. Les clients DPMI ne doivent pas utiliser l'instruction PUSHFpour 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 virtuel
Si 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.