RFR(xs): 8075044 : Query dbghelp.dll version number at run time, not at compile time

Thomas Stüfe thomas.stuefe at gmail.com
Tue Mar 17 16:22:28 UTC 2015


Hi Markus,

you are right :(

When I originally posted the fix, I had looked at the resulting minidump in
a debugger, but I didn't notice that the thread information dumped with
MiniDumpWithThreadInfo were missing.

When I checked, I saw exactly the same behaviour you see on your machine. I
tested on a windows 7 box and on an old win2003 server. ImageHlpApiVersion()
does not seem to return anything usable. Always returns 4.0.5 for all
dbghelp.dll versions I tested. MSDN was fooling me ("Retrieves the version
information of the DbgHelp library installed on the system.").

API_VERSION_NUMBER, as a compile time constant, is only useful to guard
against compile errors when using too old header files. However, it is
completely undocumented.

Another way to determine dbghelp.dll version would be to probe for APIs
which are tied to dbghelp.dll versions (see
https://msdn.microsoft.com/en-us/library/windows/desktop/ms679294%28v=vs.85%29.aspx).
I tried this and found also an inconsistent picture. On windows 2003 the
dbghelp.dll only exported some APIs introduced for certain dbghelp.dll
versions, but not all of them (so, e.g., it exported all APIs introduced
with version 6.1, but "EnumDirTree()", which is available since 5.2, was
missing).

Bottomline, I now do not see a reliable way to determine the dbghelp.dll
version at runtime nor at compile time. Microsoft itself recommends to ship
the dbghelp.dll from the debugging kit together with the application.

So the best way to deal with an unknown dbghelp.dll would be to just call
MiniDumpWriteDump() with all dumptype flags - if that fails, to fall back
to a subset of those flags. Which is what the old code already does.

In the light of this, I think I close the bug report without fixing,
because the code cannot really be improved.

Thank you for reviewing and testing this, and sorry for the bad patch.

Thomas


On Mon, Mar 16, 2015 at 8:04 PM, Markus Gronlund <markus.gronlund at oracle.com
> wrote:

> Hi Thomas,
>
> I am a bit worried about the changes from the API_VERSION constant which
> is defined in ImageHlp.h as:
>
> #define API_VERSION_NUMBER 11
>
> to using the runtime values returned in the API_VERSION struct from
> calling dbghelp::ImagehlpApiVersion() without any conversions:
>
> This is what I get on my laptop (win7 x86 /32-bit)
>
> dbghelp::ImagehlpApiVersion() // function pointer via
> C:\Windows\System32\dbghelp.dll (some old version: 6.1.7061.17514):
>
>    +0x000 MajorVersion     : 4
>    +0x002 MinorVersion     : 0
>    +0x004 Revision         : 5
>    +0x006 Reserved         : 0
>
>
> I thought this might be due to the fact of an older version of dbghelp.dll
> - I therefore set the function pointer to the Windows SDK 8.1 version of
> dbghelp.dll (6.3.9600.16384):
>
>    +0x000 MajorVersion     : 4
>    +0x002 MinorVersion     : 0
>    +0x004 Revision         : 5
>    +0x006 Reserved         : 0
>
> Same data.
>
> I also queried Imagehlp.dll (6.1.7601.18288) using the same API:
>
>    +0x000 MajorVersion     : 4
>    +0x002 MinorVersion     : 0
>    +0x004 Revision         : 5
>    +0x006 Reserved         : 0
>
> I am not sure if "MajorVersion == 4" is the same as / should be
> interpreted the same as "#define API_VERSION_NUMBER 11" ?
>
> In any case, only looking at the MajorVersion number returned with no
> adaptation changes behavior:
>
>   // Older versions of dbghelp.h doesn't contain all the dumptypes we
> want, dbghelp.h with
>   // API_VERSION_NUMBER 11 or higher contains the ones we want though
>
>   if (version->MajorVersion >= 11) {
>     dumpType = (MINIDUMP_TYPE)(dumpType | MiniDumpWithFullMemoryInfo |
> MiniDumpWithThreadInfo |
>                              MiniDumpWithUnloadedModules);
>   }
>
> I previously go the 11 from the constant, but now as I described above, I
> am getting 4, and therefore, less information in the .mdmp.
>
> Are you pulling out a 11 from MajorVersion?
>
> /Markus
>
>
>
> -----Original Message-----
> From: Thomas Stüfe [mailto:thomas.stuefe at gmail.com]
> Sent: den 16 mars 2015 12:33
> To: Staffan Larsen
> Cc: hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR(xs): 8075044 : Query dbghelp.dll version number at run
> time, not at compile time
>
> Hi all,
>
> still need a second reviewer and also a sponsor. Thanks!
>
> Thomas
>
> On Thu, Mar 12, 2015 at 1:58 PM, Staffan Larsen <staffan.larsen at oracle.com
> >
> wrote:
>
> > Looks good!
> >
> > Thanks,
> > /Staffan
> >
> > > On 12 mar 2015, at 13:50, Thomas Stüfe <thomas.stuefe at gmail.com>
> wrote:
> > >
> > > Hi all,
> > >
> > > please take a look at this tiny change:
> > >
> > > webrev:
> > http://cr.openjdk.java.net/~stuefe/webrevs/8075044/webrev.01/webrev/
> > > bug: https://bugs.openjdk.java.net/browse/JDK-8075044
> > >
> > > This changes the version number query for dbghelp.dll from a compile
> > > time check to a run time check.
> > >
> > > Thanks!
> > >
> > > Thomas Stuefe
> >
> >
>


More information about the hotspot-runtime-dev mailing list