ScardGetStatusChange() API May Cause Deadlock in Smart Card Resource Manager

ID: Q235899

The information in this article applies to:

Microsoft Windows NT Server version 4.0
Microsoft Windows NT Workstation version 4.0

SYMPTOMS

The Smart Card Resource Manager may stop responding (hang) in the following situation:

There are two processes (A and B) each with a single thread gaining access to the same card (in the same reader) simultaneously. Each of the processes runs the following sequence in a finite loop:

SCardEstablishContext
SCardConnect
SCardGetStatusChange(SCARD_STATE_UNWARE,.....)
SCardBeginTransaction
SCARDTransmit (many times)
.....
SCardEndTransaction
SCardDisconnect
SCardReleaseContext

The two processes run exactly the same code. After running the code for several minutes (from 2 to 15 minutes), the two processes hang and no other program may be able to gain access to the same reader. However, another reader connected to the system can be accessed through the Resource manager.

Even if you are forced to quit the two programs, the reader is still inaccessible. To "unblock" the reader, the computer must either be restarted or you must quit the Resource Manager program through a utility like Pview.exe. You can also use Task Manager and then restart Resource Manager. If you quit then restart Resource Manager, the two other programs are immediately unblocked.

RESOLUTION

To resolve this problem, obtain the latest service pack for Windows NT 4.0 or the individual software update. For information on obtaining the latest service pack, please go to:

http://www.microsoft.com/windows/servicepacks/

Q152734 How to Obtain the Latest Windows NT 4.0 Service Pack

For information on obtaining the individual software update, contact Microsoft Product Support Services. For a complete list of Microsoft Product Support Services phone numbers and information on support costs, please go to the following address on the World Wide Web:

http://www.microsoft.com/support/supportnet/overview/overview.asp

STATUS

Microsoft has confirmed this to be a problem in Windows NT 4.0. This problem was first corrected in Windows NT 4.0 Service Pack 6.

Additional query words:

Keywords : kbbug4.00 kbfix4.00 NT4SP6Fix
Version : winnt:4.0
Platform : winnt
Issue type : kbbug