DLL analysis

Enterprise Edition only

DLL analysis works with conventional library files. In Visual Basic you use DLLs via the Declare statement. VB.NET also offers the <DLLImport> attribute to call DLLs. DLL analysis reads the contents of library files and also displays declare syntax information.

When is it useful?

DLL analysis reveals all available procedures in a conventional library file. A built-in API database shows the declaration format of a large number of Windows API functions.

Find out all available procedures in a library.
Review your declarations and find alternative procedures to consider.
Find undeclared procedures.
Check if any procedure is declared multiple times at different locations or with a different name or parameters.
Look up the correct declaration format of 1600 API calls.

What belongs to DLL analysis?

The following features are part of DLL analysis. They require the Enterprise Edition to function. They are also enabled in the demo version and Standard/Pro Editions when a maximum of 10 source files have been analyzed.

Read DLL file contents to list procedures in DLL. Enabled at start of analysis.
Display DLL procedure declaration syntax.
DLL declaration related problem detection rules, as listed below.

All editions can fully analyze Declare statements and <DLLImport> procedures, but the other features are limited to the Enterprise Edition.

Reading the libraries

DLL analysis reads the function export table of a PE (Portable Executable) file. The export table lists the procedures available in the library. You need to enable this feature when you open the file(s) to analyze.

Any 32-bit PE file that has a function export table can be analyzed. It's required that this file is referenced in the source via a Declare statement or via a <DLLImport> attribute. The analysis is not limited to files with the .dll extension, it also works with .exe and .ocx files, provided that they export functions. A typical case for DLL analysis is when you call the Windows API routines.

Declare syntax

For more than 1600 Win32 API functions, Project Analyzer displays the Declare statement syntax as given by Microsoft. This feature is useful if you want to compare an existing Declare statement with the canonical declaration or if you want to learn how to declare and use an undeclared function.

Declaration format is available for the following Win32 API libraries: kernel32, user32, advapi32.dll, gdi32, winspool.drv, winmm.dll, mpr.dll, netapi32.dll, lz32.dll, imm32.dll, shell32.dll, version.dll, comctl32.dll, ole32.dll, odbc32.dll, pdh.dll, mapi32.dll. Not all functions have a declaration available. Most notably, only the Ansi "A" calls are included while the Unicode "W" versions are missing. Usually the W declaration is similar to the A declaration. Consult MSDN on the availability of Unicode support in each API. Note that declarations are not available for any new APIs introduced with Windows XP or Windows Server 2003.

It's perfectly all right for your own declarations to differ from the canonical declaration. You can declare the same procedure in a number of ways, varying the parameter data types, parameter passing convention, parameter names and the procedure name. Several declarations may be required for the same function to work right in the intended use.

To view the available declarations, click on a procedure in a library file. You will see the declarations listed. The canonical declaration, if available, is given first. If there are 2 or more declarations, your declarations differ from the canonical declaration and/or from each other. To find your declaration(s) of a DLL procedure, open the Proc info tab in there, the call trees at the bottom left of the main screen.

The declarations are given in either classic VB syntax or VB.NET syntax depending on which projects you have analyzed.

The data is in VB classic syntax. In VB classic, the syntax is useful "as is".
In VB.NET projects, the declarations are slightly modified to suit VB.NET. The data types are modified as follows: Integer → Short, Long → Integer. Some declarations use the parameter type As Any. This syntax is not allowed in VB.NET. You will need to find out the correct data type with which to replace As Any. In some cases, you may also need to do some manual adjustments for .NET to call the APIs correctly. If in doubt, consult MSDN.
If you're doing a mixed analysis of both VB classic and VB.NET code, the declarations are in VB.NET format.

DLL analysis related problem detection

You can monitor DLL related issues with the code review feature.

Return value discarded. Read more

Procedure not found in library. Read more

Declare contains ordinal number. Read more

DLL analysis example

This is an example of a declare statement.

Declare Function ChooseFont Lib _
   "comdlg32.dll" Alias "ChooseFontA" _
   (pChoosefont As CHOOSEFONT) As Long

Sub SelectFont()
   ...
   retval = ChooseFont(CF)
   ...
End Sub

This function is declared in the file comdlg32.dll as ChooseFontA. In the call trees, you should see this sequence:

Sub SelectFont
  › Declare Function ChooseFont
    › ChooseFontA

This means that your VB Sub SelectFont calls ChooseFont, which in turn gets redirected to ChooseFontA in comdlg32.dll.

DLL analysis reveals that there is an alternative function available in the same library. The alternatives are ChooseFontA and ChooseFontW. (A means the Ansi version you usually use with VB Classic, W is the wide character/Unicode version.) The operating systems for ChooseFontA are Win95 and later, but ChooseFontW requires WinNT or better.

Limitations

Unnamed DLL procedures are not listed unless explicitly declared in VB code. Usually DLL procedures have a name. Some libraries contain procedures that have no name and that are only known by their ordinal number. DLL analysis ignores these procedures as you don't usually call them from VB.

16-bit libraries (used by VB3 and the 16-bit version of VB4) cannot be analyzed. DLL analysis works only with files from which you declare at least one procedure and that can be found on the system on the normal library search path.

We do not guarantee the correctness of the declaration syntax data. The data comes from Microsoft and we use it without modifications. You should always consult MSDN for the latest and most accurate declaration information before changing your code.

DLL search path

DLL procedures are usually declared without giving a path to the DLL file. The normal Windows search order for a DLL is the following.

Directory from which app loaded (executable directory)
Current directory (can be overridden with an API call to SetDllDirectory)
System directory
16-bit system directory
Windows directory
Directories listed in the PATH environment variable

What is more, WinXP and later have a setting where the current directory is searched only after the System and Windows directories.

The search order Project Analyzer uses is somewhat different, especially because the executable directory and the current directory are not known. The search order is the following:

Directory of the project's executable file, or if not defined, directory of the project file
System directory (32-bit only, the 16-bit SYSTEM directory is not searched as 16-bit files are not supported)
Windows directory
Directories listed in the PATH environment variable

On Windows 2000 and later, if the executable file directory contains a "redirect file" named myproject.exe.local, any DLLs placed in this directory have precedence over DLLs installed in other directories. This affects Declares using an absolute path to the DLL (this should be rare).

To force Project Analyzer to read a certain version of a DLL, place it in the executable directory. This is the directory where the project was last compiled. Notice that .NET projects may compile in several directories based on the selected configuration (Debug, Release and so on).

DLL, COM and .NET

DLL analysis is not to be confused with COM or .NET assembly analysis, even though COM/.NET files can have the .dll file extension. DLL analysis doesn't read type library data, while COM and .NET assembly analysis does.