From: SMTP%"ess013@comm.mot.com" 7-NOV-1997 16:36:14.46 To: CC: , Subj: RE: [ntdev] COM functions causing serial port failure Return-Path: owner-ntdev@atria.com Received: by arisia.gce.com (UCX V4.1-12C, OpenVMS V7.1 VAX); Tue, 4 Nov 1997 16:10:28 -0500 Received: from gw.atria.com (gw.atria.com [192.88.237.2]) by mercury.mv.net (8.8.8/mem-971025) with SMTP id RAA20405 for ; Mon, 3 Nov 1997 17:54:31 -0500 (EST) Received: by gw.atria.com id Sun, 2 Nov 1997 13:42:18 -0500 Received: from motgate.mot.com by gw.atria.com id Sun, 2 Nov 1997 13:42:15 -0500 From: ess013@comm.mot.com Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id KAA03832 for ; Sun, 2 Nov 1997 10:52:24 -0600 (CST) Comments: ( Received on motgate.mot.com from client mothost.mot.com, sender ess013@comm.mot.com ) Received: from il02dns1.comm.mot.com (il02dns1.comm.mot.com [145.1.3.2]) by mothost.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id KAA14911 for ; Sun, 2 Nov 1997 10:52:11 -0600 (CST) Received: from plnt004.comm.mot.com (plnt004.comm.mot.com [145.2.198.62]) by il02dns1.comm.mot.com (8.7.5/8.7.3) with SMTP id KAA12500 for ; Sun, 2 Nov 1997 10:52:11 -0600 (CST) Received: by plnt004.comm.mot.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BCE785.C01D17D0@plnt004.comm.mot.com>; Sun, 2 Nov 1997 11:52:09 -0500 Message-ID: To: Cc: , Subject: RE: [ntdev] COM functions causing serial port failure Date: Sun, 2 Nov 1997 11:52:08 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ntdev@atria.com Precedence: bulk The funny thing is that it is an error that is not even listed in the documentation for the function--0xC0000034, which translates to STATUS_OBJECT_NAME_NOT_FOUND. Even when I don't include the COM stuff in the tests, very occasionally I will get this same failure for no apparant reason. I know there is nothing wrong with the object name, and even if there were, I would get STATUS_OBJECT_NAME_INVALID as a return value (know this from experience). BTW--gets even wierder, when I was messing around with this stuff yesterday, I did see the call to IoGetDeviceObjectPointer actually succeed occasionally with the COM stuff included, which I never had before--it worked maybe one out of 20 times. Thanks, Sherri Sherri Scharf Software Engineer Motorola, Land Mobile Products Sector >---------- >From: Dave Cox[SMTP:dave@silcom.com] >Sent: Saturday, November 01, 1997 4:34 PM >To: ess013@comm.mot.com >Subject: Re: [ntdev] COM functions causing serial port failure > >Sherri, > >Maybe inclusion of the COM calls causes OLE DLLs to link which might >not otherwise, and even if you never call into them explicitly, their >DllMain routines run when they are attached to your process. I don't >know what or why, but there might be something there that affects >your driver's behavior. > >Also, what is the NTSTATUS error returned by IoGetDeviceObjectPointer? >This can help you figure out what is going wrong. > >Dave Cox >Miramar Systems > >ess013@comm.mot.com wrote: >> >> Hi, >> >> Here's a wierd one. A couple weeks ago I sent a note out about failing >> to claim serial ports with IoGetDeviceObjectPointer. It turned out >> that >> this was occurring when in the test app I was using to call the driver >> there was a certain portion of code that was being compiled--not >> executed, just compiled. >> >> Well, I narrowed it down, and here's the deal. Whenever there are >> calls >> to the COM functions CoInitialize and CoCreateInstance being COMPILED >> in >> the test app, the driver call to IoGetDeviceObjectPointer will fail >> when >> the test is run. This code is NOT being executed, it is only being >> compiled. The code that is being executed is unchanged between the >> working and non-working tests. >> >> Note that the same test code works fine when testing the win95 version >> of the driver--and there it works when that portion of code is >> executed >> as well as when it is compiled and not executed. >> >> Anyone have any ideas why simply compiling these functions in a >> user-mode app would cause a call to IoGetDeviceObjectPointer at the >> driver level to fail? >> >> Thanks!! >> Sherri >> >> Sherri Scharf >> Software Engineer >> Motorola, Land Mobile Products Sector >> >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> [ To unsubscribe, send email to ntdev-request@atria.com with body >> UNSUBSCRIBE (the subject is ignored). ] > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ]