TAPI/Modem Error Code

[Ken Roberts]

We are getting the following error occasionally when initializing a
modem using TAPI: "Modem Initialization failed with error 00000020".
Below is the modem log. Could you give an explaination of the error
code and the possible cause?

04-05-2006 23:01:15.424 - File: C:\WINNT\system32\unimdm.tsp, Version
5.0.2195 - Retail
04-05-2006 23:01:15.424 - File: C:\WINNT\system32\unimdmat.dll, Version
5.0.2195 - Retail
04-05-2006 23:01:15.424 - File: C:\WINNT\system32\uniplat.dll, Version
5.0.2195 - Retail
04-05-2006 23:01:15.440 - File: C:\WINNT\system32\drivers\modem.sys, Version
5.0.2195 - Retail
04-05-2006 23:01:15.440 - File: C:\WINNT\system32\modemui.dll, Version
5.0.2195 - Retail
04-05-2006 23:01:15.440 - Modem type: Digi AccelePort RAS Modem
04-05-2006 23:01:15.440 - Modem inf path: oem2.inf
04-05-2006 23:01:15.440 - Modem inf section: AccelePort_RAS.PnP
04-05-2006 23:01:15.440 - Opening the modem device failed with error 00000020

[Andreas Marschall [MVP TAPI]]

"Ken Roberts" <KenRo...@newsgroups.nospam> schrieb im Newsbeitrag
news:0C5C2138-A9F0-4432...@microsoft.com...

Ken,
did you configure the correct COM port for the modem?
Is the modem being used by another app (non TAPI) in parallel so that the COM
port is already opened?

--
Best Regards
Andreas Marschall
Microsoft MVP for TAPI / Windows SDK
TAPI / TSP Developer and Tester
My TAPI and TSPI FAQ:
http://www.I-B-A-M.de/Andreas_Marschall's_TAPI_and_TSPI_FAQ.htm
My Toto® Tools (a collection of free, mostly TAPI related tools):
http://www.i-b-a-m.de/Andreas_Marschall's_Toto_Tools.htm
TAPI development around the world (Frappr! map):
http://www.frappr.com/TAPIaroundTheWorld
* Please post all messages and replies to the newsgroup so all may
* benefit from the discussion. Private mail is usually not replied to.
* This posting is provided "AS IS" with no warranties, and confers no rights.

[Jack]

If that can be any help, see this:
http://www.itech2000.net/cgi-bin/index.pl?page=modems
Jack

"Ken Roberts" <KenRo...@newsgroups.nospam> wrote in message
news:0C5C2138-A9F0-4432...@microsoft.com...

[Ken Roberts]

Andreas,
Thanks for responding. Our application runs continuously looking waiting
for calls from remote embedded data collection devices. The application
re-initializes the line if a call has not been recieved in 12 hours just to
make sure it is still OK. This is when the error occurred. We are using an
8-port PCI modem card from Digi. No other app is accessing the port. Up
until the attempted refresh the line in question had been operating normally
for weeks. We perfromed a manual re-initialization hous later and the line
came up fine. Whatever the problem was it seems to be transitory. Is it
possible that if a call was coming at the same time we were closing and
re-opening the port could have caused this problem?

Thanks,
Ken

[Jeffrey Tan[MSFT]]

Hi Ken,

I will give this issue a research sometime later, I will reply to you ASAP.
Thanks

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

[Jeffrey Tan]

Hi Ken,

Sorry for letting you wait.

Based on our research and discussion, this is most likely neither a Unimodem
nor a TAPI problem. Problem 1a) below is the only TAPI mistake that is
possible. Everything else suggests a problem with non-microsoft code or a
bug in Unimodem.

This error indicates that CreateFile() on the COM port failed with error
0x20.

From WinError.h: #define ERROR_SHARING_VIOLATION 32L

I can imagine only these ways for this error to occur:

1) The IO manager itself returned this error because the device is
“single open” and the device is already open. I’ve seen this for a
couple of reasons:

a) The application uses lineGetID(…, “comm/datamodem”, …) and
forgot to call CloseHandle() on the resulting file handle. Or it closed the
handle asynchronously, after Unimodem failed to re-open the port.

http://groups.google.com/group/microsoft.public.win32.programmer.tapi/browse_thread/thread/d70df434e31179b7/eb5ef8e05d8ce45d?lnk=st&q=closehandle+lineopen+linegetid+LINEERR_OPERATIONFAILED&rnum=1&hl=en#eb5ef8e05d8ce45d

b) Another application opened the port immediately after Unimodem
closed it. Maybe this other application opened it temporarily? Maybe this
would be Digi software for managing their hardware?

o You can run PortMon
(http://www.sysinternals.com/utilities/portmon.html) to see this happen.

c) Another kernel component (maybe the Digi serial driver itself or
maybe a 3rd party serial filter driver) has a handle/refcount to the open
device that didn’t get closed immediately.

2) The serial port device driver itself returned this error. If true,
then the reason “why” could only be answered by Digi. However, there
could hypothetically be a 3rd party serial port filter driver that returned
this error. I've never heard of one, but this type of error frequently
occurs with files because of Virus Scanner file system filter drivers.

3) The Unimodem “modem” kernel driver failed IRP_MJ_CREATE for some
other reason. I’ve never heard of this happening, but it is hypothetically
possible. The first two reasons are much more likely.

>> Is it possible that if a call was coming at the same time we were closing
>> and re-opening the port could have caused this problem?

Because the error comes from CreateFile(), this is very unlikely. Software
(like Unimodem) simply can not know about an incoming call until after it
has opened the port. Hardware is usually not checked until after
CreateFile() succeeds.

It is hypothetically possible that the Digi serial port driver will fail
IRP_MJ_CREATE with this error because an incoming call exists. But this
seems *very* unlikely. Digi is a serial driver and an incoming call is
identified by a textual "RING" string sent by the modem. The digi drivers
won't know that the text is a modem ringing or any other serial-connected
device.

Note that lineOpen() will fail (probably with LINEERR_OPERATIONFAILED) so
the customers application can detect this problem. When they detect
failure, they could launch “handle.exe > c:\handles.txt” to hopefully
capture a transient problem. Note that Handle is another tool from
http://www.sysinternals.com.

If the problem really is transient, then they can try calling lineOpen()
again later.

If this doesn't identify the problem, then it will require an EE to do
kernel debugging to identify why IRP_MJ_CREATE failed.

Hope this information helps you!

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

[Ken Roberts]

Jeffrey,

Thanks for your support on this issue. We will investigate if we are
closing the port correctly.

Ken Robertss

[Jeffrey Tan[MSFT]]

Ok, if you have any further problem, please feel free to post. Thanks