Driver build problem using VC 8 compiler

NTDEV
2

Why change compilers? If you are going to retain nt4 compatability you
should stay with the toolset you are using.

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Anupam Aishwarya
Sent: Thursday, July 06, 2006 6:03 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Driver build problem using VC 8 compiler

Hi,
I work on a file-system driver as part of my job. Currently the driver is
supported on all windows platforms since NT4 onwards. The build env is as
follows:
Compiler - VC 6 compiler
DDK - NT4 DDK
Platform SDK - Nov 2001

Recently, there is a move to upgrade the compiler to VC 8. While using VC 8
to build my driver, I am getting the following linker errors:

Error LNK2019: Unresolved external symbol __SEH_epilog in function
_FastIoLockFunc @ 36
&
Error LNK2019: Unresolved external symbol __SEH_prolog in function
_FastIoLockFunc @ 36

In the code, this points to the beginning of a try-finally construct. I know
that there has been a change in the way the VC 8 compiler handles OS
specific SEH, and used /EHa compiler option but to no avail. Any help
possible here? :frowning:

http:ture-home.htm/xxxxx@Middle5?PARTNER=3> — Questions? First check the
Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 To
unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</http:>

3

I’ve always been under the impression building a driver with VS and NOT the ddk build utility was asking for trouble. I’ve read many threads stating only compile drivers with the DDk build compiler and linker; has this changed?

“is it possible to wholly remove try-finally blocks and replace them with do…while or something similar constructs?”

lol - replace try-finally with do…while?

do while(systemCrashing)
{
DbgPrint(“damnit”);
}

m.

4

> Yes thats true. Actually my driver is part of a larger product and the

whole build env. is moving to the .Net 2005 compiler.

We have removed all errors in the build process except this one.
If there are no windows APIs which generate exceptions, is it possible to
wholly remove try-finally blocks and replace them with do…while or
something similar constructs?
Can’t you use one of the newer DDKs with NT4 compatibility? Or is NT4 compatibility even needed?

Also, I think the problem you have is both, in the headers *and* the libs. Since the compiler is responsible for implementing the actual logics behind try/finally and try/except it needs some “intrinsic” (not the usual meaning) functions which support this. You have hit this case …

Best regards,

Oliver

May the source be with you, stranger :wink:

ICQ: #281645
URL: http://assarbad.net

5

> I’ve always been under the impression building a driver with VS and NOT

the ddk build utility was asking for trouble. I’ve read many threads
stating only compile drivers with the DDk build compiler and linker; has
this changed?
Nope, but the NT4 DDK and also the W2K DDK (if I recall it correctly) do not have their own compilers (yet their own BUILD utility).

But for those DDKs having their own compiler and linker the statement is still true.

Oliver

–

May the source be with you, stranger :wink:

ICQ: #281645
URL: http://assarbad.net

6

You’ll have to forgive me, can’t think clearly right now (or ever for that matter). Anyhow, I just recalled an instance where try…finally wasn’t working, but __try … __finally did.

strange,

m.

7

try is for C++, __try is for C (SEH), and try is #define’ed as __try in
C:\WINDDK\3790.1830\inc\ddk\w2k\warning.h (or whatever).

----- Original Message -----
From: xxxxx@comcast.net
To: Windows System Software Devs Interest List
Sent: Thursday, July 06, 2006 8:57 AM
Subject: [ntdev] Driver build problem using VC 8 compiler

You’ll have to forgive me, can’t think clearly right now (or ever for that matter). Anyhow, I just recalled an instance where try…finally wasn’t working, but __try … __finally did.

strange,

m.

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

8

I think you’re going to have to separate out your user-mode compiler and
kernel-mode compiler for this project. IMO, it is a mistake to try to
use VS8 with the NT 4.0 DDK. It sounds to me like there is too much of
an incompatility between the compiler the NT 4.0 DDK libs were built
with and VS8.

It will be some work to restructure your build system to handle this,
but in the end, I think you will have a more stable product. It will
probably save you time in the long run because you will just end up
spending that time debugging and hacking around nasty bugs due to the
incompatibility.

Beverly

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Anupam Aishwarya
Sent: Thursday, July 06, 2006 9:09 AM
To: Windows System Software Devs Interest List
Subject: Re: Re: Re: Re: RE: [ntdev] Driver build problem using VC 8
compiler

Tried that already… it gives the same linker error :frowning:

*********************
You’ll have to forgive me, can’t think clearly right now (or ever for
that matter). Anyhow, I just recalled an instance where try…finally
wasn’t working, but __try … __finally did. strange, m.

On Thu, 06 Jul 2006 Anupam Aishwarya wrote :

If our attempts to build with VS 8 prove futile, we might have to
upgrade the DDK/stay with VS 6.
I was only wondering if we could set any compiler/linker flags or make
some changes so as to work around the try-finally block (go back to VS 6
style SEH handling?)

On Thu, 06 Jul 2006 Oliver Schneider wrote :
> > Yes thats true. Actually my driver is part of a larger product and
the
> > whole build env. is moving to the .Net 2005 compiler.
> >
> > We have removed all errors in the build process except this one.
> > If there are no windows APIs which generate exceptions, is it
possible to
> > wholly remove try-finally blocks and replace them with do…while
or
> > something similar constructs?
>Can’t you use one of the newer DDKs with NT4 compatibility? Or is NT4
compatibility even needed?
>
>Also, I think the problem you have is both, in the headers *and* the
libs. Since the compiler is responsible for implementing the actual
logics behind try/finally and try/except it needs some “intrinsic” (not
the usual meaning) functions which support this. You have hit this case
…
>
>
>Best regards,
>
>Oliver
>–
>---------------------------------------------------
>May the source be with you, stranger :wink:
>
>ICQ: #281645
>URL: http://assarbad.net
>
>—
>Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
>To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

http:ignature-home.htm/xxxxx@Middle5?PARTNER=3> — Questions? First
check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</http:>

9

The various try … finally combinations have been what has always blocked
using anything other than the blessed compiler for the DDK. In the case of
NT4 that is VS6 compiler, trying anything else is just going to give you
problems.

Of course why you would want to continue to support NT4.0 is a mystery. You
are giving up a lot of capabilities in the DDK and runtimes, to support an
OS version that is no longer supported by Microsoft. You would be much
better off, freezing the old product for NT4.0 and doing the upgrade for
Windows 2000 and later.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

“Anupam Aishwarya” wrote in message
news:xxxxx@ntdev…
Tried that already… it gives the same linker error :frowning:

*********************
You’ll have to forgive me, can’t think clearly right now (or ever for that
matter). Anyhow, I just recalled an instance where try…finally wasn’t
working, but try … finally did. strange, m.

On Thu, 06 Jul 2006 Anupam Aishwarya wrote :
>If our attempts to build with VS 8 prove futile, we might have to upgrade
>the DDK/stay with VS 6.
>I was only wondering if we could set any compiler/linker flags or make some
>changes so as to work around the try-finally block (go back to VS 6 style
>SEH handling?)
>
>
>On Thu, 06 Jul 2006 Oliver Schneider wrote :
> > > Yes thats true. Actually my driver is part of a larger product and the
> > > whole build env. is moving to the .Net 2005 compiler.
> > >
> > > We have removed all errors in the build process except this one.
> > > If there are no windows APIs which generate exceptions, is it possible
> > > to
> > > wholly remove try-finally blocks and replace them with do…while or
> > > something similar constructs?
> >Can’t you use one of the newer DDKs with NT4 compatibility? Or is NT4
> >compatibility even needed?
> >
> >Also, I think the problem you have is both, in the headers and the
> >libs. Since the compiler is responsible for implementing the actual
> >logics behind try/finally and try/except it needs some “intrinsic” (not
> >the usual meaning) functions which support this. You have hit this case
> >…
> >
> >
> >Best regards,
> >
> >Oliver
> >–
> >---------------------------------------------------
> >May the source be with you, stranger :wink:
> >
> >ICQ: #281645
> >URL: http://assarbad.net
> >
> >—
> >Questions? First check the Kernel Driver FAQ at
> >http://www.osronline.com/article.cfm?id=256
> >
> >To unsubscribe, visit the List Server section of OSR Online at
> >http://www.osronline.com/page.cfm?name=ListServer
>
>—
>Questions? First check the Kernel Driver FAQ at
>http://www.osronline.com/article.cfm?id=256
>
>To unsubscribe, visit the List Server section of OSR Online at
>http://www.osronline.com/page.cfm?name=ListServer

10

Of course you are still going to get a linker error. The libraries you
are linking to don’t have the symbol you need. This was stated earlier.
Try this linker option: /VERBOSE:LIB

That will tell you what libs are being searched.

-Jeff

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Anupam Aishwarya
Sent: Thursday, July 06, 2006 9:09 AM
To: Windows System Software Devs Interest List
Subject: Re: Re: Re: Re: RE: [ntdev] Driver build problem using VC 8
compiler

Tried that already… it gives the same linker error :frowning:

*********************
You’ll have to forgive me, can’t think clearly right now (or ever for
that matter). Anyhow, I just recalled an instance where try…finally
wasn’t working, but __try … __finally did. strange, m.

On Thu, 06 Jul 2006 Anupam Aishwarya wrote :

If our attempts to build with VS 8 prove futile, we might have to
upgrade the DDK/stay with VS 6.
I was only wondering if we could set any compiler/linker flags or make
some changes so as to work around the try-finally block (go back to VS 6
style SEH handling?)

On Thu, 06 Jul 2006 Oliver Schneider wrote :
> > Yes thats true. Actually my driver is part of a larger product and
the
> > whole build env. is moving to the .Net 2005 compiler.
> >
> > We have removed all errors in the build process except this one.
> > If there are no windows APIs which generate exceptions, is it
possible to
> > wholly remove try-finally blocks and replace them with do…while
or
> > something similar constructs?
>Can’t you use one of the newer DDKs with NT4 compatibility? Or is NT4
compatibility even needed?
>
>Also, I think the problem you have is both, in the headers *and* the
libs. Since the compiler is responsible for implementing the actual
logics behind try/finally and try/except it needs some “intrinsic” (not
the usual meaning) functions which support this. You have hit this case
…
>
>
>Best regards,
>
>Oliver
>–
>---------------------------------------------------
>May the source be with you, stranger :wink:
>
>ICQ: #281645
>URL: http://assarbad.net
>
>—
>Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
>To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

http:ignature-home.htm/xxxxx@Middle5?PARTNER=3> — Questions? First
check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</http:>

11

Let’s give it another try: you have not set /GS somewhere during the build process in VS 2005, have you?

Actually the symbols don’t look SEH4-specific, but nevertheless I’d like to make this sure.

Oliver

May the source be with you, stranger :wink:

ICQ: #281645
URL: http://assarbad.net

12

Anupam Aishwarya wrote:

Hi Oliver, I add the /GS- flag in order to remove buffer security
check for the code. Without this flag, I get a large number of linker
errors (such as unreferenced symbol __security_cookie…etc).

The KEY problem is that the libraries in the NT4 DDK were built assuming
the Visual Studio 6 compiler would be used. Each compiler makes certain
assumptions about the libraries that will be available, and you are
violating those assumptions. It is NEVER going to work reliably.

This is exactly why Microsoft started shipping the compilers with the
DDK. In the old days, every time a new DDK or a new compiler came out,
there would be a whole rash of angry newsgroup messages from people who
assumed that they could throw any old set of tools together and make it fly.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

13

> I’ve always been under the impression building a driver with VS and NOT the

ddk build utility was asking for trouble.

Yes, but this is the only way for NT4-compatible binary.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

14

Wrong, NT4 still used the DDK build, it was just that you needed to install
VC6 before the DDK.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
>> I’ve always been under the impression building a driver with VS and NOT
>> the
>>ddk build utility was asking for trouble.
>
> Yes, but this is the only way for NT4-compatible binary.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>

15

> > Yes, but this is the only way for NT4-compatible binary.

Wrong, NT4 still used the DDK build, it was just that you needed to
install VC6 before the DDK.
Well, strictly speaking you would not need the BUILD utility, though :wink: …

It is just a convenience tool. It helps streamline the build process, but it is not *vital* to build a driver (not even an NT4 one). I remember putting together NT scripts (.cmd/.bat) or manually configuring the projects just to get along without the BUILD utility because it seemed so ugly to me at that time. Using DDKBUILD I am fine with it now :smiley:

But back to topic.

Hi Oliver, I add the /GS- flag in order to remove buffer security check
for the code. Without this flag, I get a large number of linker errors
(such as unreferenced symbol __security_cookie…etc).
Never mind. Thought it could be a way. I do not understand how the linker can complain about a symbol that is not used in your code or the linked-to code (the NT4 DDK libs), though :-\ … could it be you do not link against the right libs?

Oliver

–

May the source be with you, stranger :wink:

ICQ: #281645
URL: http://assarbad.net

16

As stated earlier the only supported build tools for the NT4 DDK are the
ones that come with VS6. As Don Burn suggested, you should freeze your NT4
functionality where it is and move forward with new functionality on
supported OS platforms (which just barely includes W2K at this point.) In
doing so you should NOT build your drivers with VS2005 but instead should
upgrade your DDK to the latest supported DDK (W2K3SP1) and build your
drivers using that DDK’s supplied toolset for the earliest rev OS release
you need to support (e.g. W2K.) You will have to rework your product build
tools, as Beverly pointed out, but in doing so you will end up with a more
maintainable and reliable build process that will work for you over future
DDK and VS releases.

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Anupam Aishwarya
Sent: Friday, July 07, 2006 3:58 AM
To: Windows System Software Devs Interest List
Subject: Re: RE: Re: Re: Re: RE: [ntdev] Driver build problem using VC 8
compiler

Thanks for all the replies! I used the -VERBOSE linker flag and I get an
output like this:

module ‘hal.lib(HAL.dll)’ unsafe for SAFESEH image.
Found _KeGetCurrentIrql@0
Referenced in **.obj
Referenced in **.obj
Referenced in …obj
Referenced in …obj
Referenced in …obj
Loaded hal.lib(HAL.dll)

.
.
Finished searching libraries
Finished pass 1
Generating non-SAFESEH image.
**fstio.obj : error LNK2019: unresolved external symbol __SEH_epilog
referenced in function _FastIoLockFunc@36
**fstio.obj : error LNK2019: unresolved external symbol __SEH_prolog
referenced in function _FastIoLockFunc@36

I am linking to the default NT4 DDK libs (HAL.lib, ntoskernel.lib,
int64.lib)

Also, just as Don suggested, we will have to review all options before
coming to a decision regarding which compiler to use and platforms to
support.

Thanks

On Thu, 06 Jul 2006 xxxxx@emc.com wrote :

Of course you are still going to get a linker error. The libraries you
are linking to don’t have the symbol you need. This was stated earlier.
Try this linker option: /VERBOSE:LIB

That will tell you what libs are being searched.

-Jeff

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Anupam Aishwarya
Sent: Thursday, July 06, 2006 9:09 AM
To: Windows System Software Devs Interest List
Subject: Re: Re: Re: Re: RE: [ntdev] Driver build problem using VC 8
compiler

Tried that already… it gives the same linker error :frowning:

*********************
You’ll have to forgive me, can’t think clearly right now (or ever for
that matter). Anyhow, I just recalled an instance where try…finally
wasn’t working, but __try … __finally did. strange, m.

On Thu, 06 Jul 2006 Anupam Aishwarya wrote :
>If our attempts to build with VS 8 prove futile, we might have to
upgrade the DDK/stay with VS 6.
>I was only wondering if we could set any compiler/linker flags or make
some changes so as to work around the try-finally block (go back to VS 6
style SEH handling?)
>
>
>On Thu, 06 Jul 2006 Oliver Schneider wrote :
> > > Yes thats true. Actually my driver is part of a larger product and
the
> > > whole build env. is moving to the .Net 2005 compiler.
> > >
> > > We have removed all errors in the build process except this one.
> > > If there are no windows APIs which generate exceptions, is it
possible to
> > > wholly remove try-finally blocks and replace them with do…while
or
> > > something similar constructs?
> >Can’t you use one of the newer DDKs with NT4 compatibility? Or is NT4
compatibility even needed?
> >
> >Also, I think the problem you have is both, in the headers *and* the
libs. Since the compiler is responsible for implementing the actual
logics behind try/finally and try/except it needs some “intrinsic” (not
the usual meaning) functions which support this. You have hit this case
…
> >
> >
> >Best regards,
> >
> >Oliver
> >–
> >---------------------------------------------------
> >May the source be with you, stranger :wink:
> >
> >ICQ: #281645
> >URL: http://assarbad.net
> >
> >—
> >Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
> >
> >To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>
>—
>Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
>To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

http:>ignature-home.htm/xxxxx@Middle5?PARTNER=3> — Questions? First
>check the Kernel Driver FAQ at
>http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
>List Server section of OSR Online at
>http://www.osronline.com/page.cfm?name=ListServer
>
>—
>Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
>To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

http:ture-home.htm/xxxxx@Middle5?PARTNER=3> — Questions? First check the
Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 To
unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</http:></http:>

17

For user mode applications, the platform SDK says to add SEHPROLOG,.OBJ
to you library list. I have no idea of how this would work in the
kernel, but you could give it a try if you have no other options, as
this is a less than desirable one.

MM

>> xxxxx@rediffmail.com 2006-07-06 06:02 >>>
Hi,
I work on a file-system driver as part of my job. Currently the
driver is supported on all windows platforms since NT4 onwards. The
build env is as follows:
Compiler - VC 6 compiler
DDK - NT4 DDK
Platform SDK - Nov 2001

Recently, there is a move to upgrade the compiler to VC 8. While using
VC 8 to build my driver, I am getting the following linker errors:

Error LNK2019: Unresolved external symbol __SEH_epilog in function
_FastIoLockFunc @ 36
&
Error LNK2019: Unresolved external symbol __SEH_prolog in function
_FastIoLockFunc @ 36

In the code, this points to the beginning of a try-finally construct. I
know that there has been a change in the way the VC 8 compiler handles
OS specific SEH, and used /EHa compiler option but to no avail. Any help
possible here? :frowning:

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

18

I build NT 4 drivers using the latest DDK (Win2003 DDK SP1). As long as 3 simple rules are followed it works fine:

  1. Use the Windows 2000 build environment, not XP or WNET
  2. Be careful not to invoke functions that don’t exist in NT 4
  3. Don’t use try/except

But I believe #3 could conceivably be resolved. The problem is try/except references functions that aren’t exported in NT 4. The solution would be to create a library file with these missing functions and link with them. Since I haven’t needed them I just never did this. SEHPROLOG.OBJ was mentioned; perhaps that is already a perfect fit for the job.

Using the newest DDK means for NT 4 drivers is great. You can junk the old DDK, the platform SDK, and the VC6 compiler. You also take advantage of a much newer compiler that generates better code.

19

And you have an untested build configuration. The tested build tools for
NT4 are VS6 + DDK 4.0.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@email.com
Sent: Thursday, July 13, 2006 7:29 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Driver build problem using VC 8 compiler

I build NT 4 drivers using the latest DDK (Win2003 DDK SP1). As long as
3 simple rules are followed it works fine:

  1. Use the Windows 2000 build environment, not XP or WNET
  2. Be careful not to invoke functions that don’t exist in NT 4
  3. Don’t use try/except

But I believe #3 could conceivably be resolved. The problem is
try/except references functions that aren’t exported in NT 4. The
solution would be to create a library file with these missing functions
and link with them. Since I haven’t needed them I just never did this.
SEHPROLOG.OBJ was mentioned; perhaps that is already a perfect fit for
the job.

Using the newest DDK means for NT 4 drivers is great. You can junk the
old DDK, the platform SDK, and the VC6 compiler. You also take advantage
of a much newer compiler that generates better code.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer