Q49377: CVP 2.30 Does Not Allow Pathnames for DLLs Specified with /L
Article: Q49377 Product(s): See article Version(s): 2.30 Operating System(s): OS/2 Keyword(s): ENDUSER | buglist2.30 | mspl13_basic Last Modified: 10-OCT-1989 Protected-mode CodeView (CVP) Version 2.30 allows debugging of dynamic link libraries (DLLs) by specifying their names on the command line with the /L switch. Because of a problem exclusive to CVP 2.30, this particular version of the debugger does not allow a pathname to be used with /L to specify the DLL's location in another directory. Therefore, all DLLs to be debugged with CVP 2.30 must reside in the current working directory. Since DLLs are also required to be in a directory that is on the LIBPATH, two copies of the DLL may need to be resident on the disk, unless the current working directory is also a LIBPATH directory. Microsoft has confirmed this to be a problem with CodeView Version 2.30. We are researching this problem and will post new information as it becomes available. When tracing a program under CodeView that calls DLLs, the only way to trace into the code of a particular DLL is if the DLL was specified ahead of time on the command line with /L when CVP was invoked. If a program statement is traced that calls a DLL that was not specified by /L, then CodeView executes all the code in the DLL and returns control back at the line following the call to the DLL. Thus, the call is handled as if the step command, rather than the trace command, had been used. You can indicate only one DLL with the /L switch, so debugging multiple DLLs requires multiple /L switches. Normally, the switch is followed by a space and the name of the DLL to be debugged, and if the DLL is not located in the current directory, a path may precede the DLL name. It is only with CVP 2.30 that this becomes a problem because a pathname is not recognized with this version, so tracing into the DLL is prevented. Unfortunately, CodeView does not display error messages for improper use of the /L switch, so if the DLL is not found, there is no message indicating this. Instead, CodeView does not allow debugging of the improperly specified DLL. Use of a pathname with /L with CVP 2.30 causes this same behavior. The only workaround for DLL debugging with CVP 2.30 is to keep a copy of the DLL in the current working directory from which CodeView is invoked. Thus, if the current directory is not a directory specified on the LIBPATH, there must be two copies of the DLL on the disk. It is very important that the two copies are exactly the same because differing code makes any attempts at debugging very difficult and confusing. A common practice is to put a period (.) as the first directory on the LIBPATH because this makes the current working directory a LIBPATH directory, eliminating the need for two copies of the DLL. More information on this practice can be found by querying on the following words: CodeView DLL debugging and libpath
THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.
Copyright Microsoft Corporation 1986-2002.