Strange linking error when using vswprintf()

Hi,

I’m trying to compile a File-System driver which uses the
wide-character string functions, but I’m hitting this strange linking
error when it comes to vswprintf().

1>blah.obj : error LNK2019: unresolved external symbol __imp__vswprintf
referenced in function _LogInput
1>objchk_w2k_x86\i386\blah.sys : error LNK1120: 1 unresolved externals

Build -L (compile only) works flawlessly but Build -cZ fails with that
error.

If I comment out that line that uses vswprintf(), or replace
vswprintf() with swprint() the linking works as expected.

I’m puzzled as to why the rest of the C Runtime functions work
(wcslen(), wcscpy(), etc…) and this particular one fails.

Please help!


Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

Quoting Caleb :

> Hi,
>
> I’m trying to compile a File-System driver which uses the
> wide-character string functions, but I’m hitting this strange linking
> error when it comes to vswprintf().
>
> 1>blah.obj : error LNK2019: unresolved external symbol imp vswprintf
> referenced in function _LogInput
> 1>objchk_w2k_x86\i386\blah.sys : error LNK1120: 1 unresolved externals
>
> Build -L (compile only) works flawlessly but Build -cZ fails with that
> error.
>
> If I comment out that line that uses vswprintf(), or replace
> vswprintf() with swprint() the linking works as expected.

I do not know why but isn’t this the perfect time to start using
RtlStringCchVPrintfW and its like?

This is a pure guess, but I think all other CRT functions
that are used by you are also exported by ntoskrnl.exe,
except for vswprintf (confirmed by depends.exe).

Don’t forget that CRT functions are not in MSVCRT.dll,
but in NTOSKRNL.EXE and their support is very limited.

L.

Use StringCchXxx or StringCbXxx functions instead.

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

----- Original Message -----
From: “Caleb”
To: “Windows File Systems Devs Interest List”
Sent: Wednesday, November 09, 2005 1:40 PM
Subject: [ntfsd] Strange linking error when using vswprintf()

> Hi,
>
> I’m trying to compile a File-System driver which uses the
> wide-character string functions, but I’m hitting this strange linking
> error when it comes to vswprintf().
>
> 1>blah.obj : error LNK2019: unresolved external symbol imp vswprintf
> referenced in function _LogInput
> 1>objchk_w2k_x86\i386\blah.sys : error LNK1120: 1 unresolved externals
>
> Build -L (compile only) works flawlessly but Build -cZ fails with that
> error.
>
> If I comment out that line that uses vswprintf(), or replace
> vswprintf() with swprint() the linking works as expected.
>
> I’m puzzled as to why the rest of the C Runtime functions work
> (wcslen(), wcscpy(), etc…) and this particular one fails.
>
> Please help!
>
>
>
> __________________________________
> Yahoo! FareChase: Search multiple travel sites in one click.
> http://farechase.yahoo.com
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

CALEB:

Because it is not exported from NTOSKRNL.EXE (or HAL.DLL or anything
else against wich you are, apparently, linking). In addition to the
other alternative that some have mentioned, you could used _vsnwprintf,
and just supply a buffer length.

MM

>> xxxxx@storagecraft.com 2005-11-09 07:35 >>>
Use StringCchXxx or StringCbXxx functions instead.

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

----- Original Message -----
From: “Caleb”
To: “Windows File Systems Devs Interest List”
Sent: Wednesday, November 09, 2005 1:40 PM
Subject: [ntfsd] Strange linking error when using vswprintf()

> Hi,
>
> I’m trying to compile a File-System driver which uses the
> wide-character string functions, but I’m hitting this strange
linking
> error when it comes to vswprintf().
>
> 1>blah.obj : error LNK2019: unresolved external symbol
imp vswprintf
> referenced in function _LogInput
> 1>objchk_w2k_x86\i386\blah.sys : error LNK1120: 1 unresolved
externals
>
> Build -L (compile only) works flawlessly but Build -cZ fails with
that
> error.
>
> If I comment out that line that uses vswprintf(), or replace
> vswprintf() with swprint() the linking works as expected.
>
> I’m puzzled as to why the rest of the C Runtime functions work
> (wcslen(), wcscpy(), etc…) and this particular one fails.
>
> Please help!
>
>
>
> __________________________________
> Yahoo! FareChase: Search multiple travel sites in one click.
> http://farechase.yahoo.com
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@evitechnology.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

First of all, thanks for the replies :slight_smile:

Secondly, I’ve tried _vsnwprintf(), but I get the same linking errors that I
get with vswprintf().

Is there anything I should be linking with in order to make this work?

Note: I cannot use the RtlStringCbXxx functions because it would require
rewriting a whole lot of code right now, and it’s too late in the game for
that.

Thanks!

“Martin O’Brien” wrote in message
news:xxxxx@ntfsd…
> CALEB:
>
> Because it is not exported from NTOSKRNL.EXE (or HAL.DLL or anything
> else against wich you are, apparently, linking). In addition to the
> other alternative that some have mentioned, you could used _vsnwprintf,
> and just supply a buffer length.
>
> MM
>
>
>>>> xxxxx@storagecraft.com 2005-11-09 07:35 >>>
> Use StringCchXxx or StringCbXxx functions instead.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> ----- Original Message -----
> From: “Caleb”
> To: “Windows File Systems Devs Interest List”
> Sent: Wednesday, November 09, 2005 1:40 PM
> Subject: [ntfsd] Strange linking error when using vswprintf()
>
>
>> Hi,
>>
>> I’m trying to compile a File-System driver which uses the
>> wide-character string functions, but I’m hitting this strange
> linking
>> error when it comes to vswprintf().
>>
>> 1>blah.obj : error LNK2019: unresolved external symbol
> imp vswprintf
>> referenced in function _LogInput
>> 1>objchk_w2k_x86\i386\blah.sys : error LNK1120: 1 unresolved
> externals
>>
>> Build -L (compile only) works flawlessly but Build -cZ fails with
> that
>> error.
>>
>> If I comment out that line that uses vswprintf(), or replace
>> vswprintf() with swprint() the linking works as expected.
>>
>> I’m puzzled as to why the rest of the C Runtime functions work
>> (wcslen(), wcscpy(), etc…) and this particular one fails.
>>
>> Please help!
>>
>>
>>
>> __________________________________
>> Yahoo! FareChase: Search multiple travel sites in one click.
>> http://farechase.yahoo.com
>>
>>
>> —
>> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@evitechnology.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

> Secondly, I’ve tried _vsnwprintf(), but I get the same linking errors that

I get with vswprintf().

Please, look at NTOSKRNL.EXE using DEPENDS.EXE
and you will find which functions are exported. This will
solve your problem faster than asking about every printf
variant via e-mail.

L.

You can simply do a wrapper for the function you want by using the Rtlxxx
functions. That will require no code rewrite, just adding a few more lines of code.

> Secondly, I’ve tried _vsnwprintf(), but I get the same linking errors that
> I get with vswprintf().


Kind regards, Dejan M.
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.

CALEB:

It’s possible that your code and NTOSKRNL.LIB have different ideas
about the wchar_t data type. Specifically, whether it is a native type
or not. I seriously doubt this is the problem, as it would affect and
wide string type, but what you want to look for is use of the
-Zc:wchar_t switch (or try adding it).

MM

>> xxxxx@yahoo.com 2005-11-10 00:30 >>>
First of all, thanks for the replies :slight_smile:

Secondly, I’ve tried _vsnwprintf(), but I get the same linking errors
that I
get with vswprintf().

Is there anything I should be linking with in order to make this work?

Note: I cannot use the RtlStringCbXxx functions because it would
require
rewriting a whole lot of code right now, and it’s too late in the game
for
that.

Thanks!

“Martin O’Brien” wrote in message
news:xxxxx@ntfsd…
> CALEB:
>
> Because it is not exported from NTOSKRNL.EXE (or HAL.DLL or anything
> else against wich you are, apparently, linking). In addition to the
> other alternative that some have mentioned, you could used
_vsnwprintf,
> and just supply a buffer length.
>
> MM
>
>
>>>> xxxxx@storagecraft.com 2005-11-09 07:35 >>>
> Use StringCchXxx or StringCbXxx functions instead.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> ----- Original Message -----
> From: “Caleb”
> To: “Windows File Systems Devs Interest List”
> Sent: Wednesday, November 09, 2005 1:40 PM
> Subject: [ntfsd] Strange linking error when using vswprintf()
>
>
>> Hi,
>>
>> I’m trying to compile a File-System driver which uses the
>> wide-character string functions, but I’m hitting this strange
> linking
>> error when it comes to vswprintf().
>>
>> 1>blah.obj : error LNK2019: unresolved external symbol
> imp vswprintf
>> referenced in function _LogInput
>> 1>objchk_w2k_x86\i386\blah.sys : error LNK1120: 1 unresolved
> externals
>>
>> Build -L (compile only) works flawlessly but Build -cZ fails with
> that
>> error.
>>
>> If I comment out that line that uses vswprintf(), or replace
>> vswprintf() with swprint() the linking works as expected.
>>
>> I’m puzzled as to why the rest of the C Runtime functions work
>> (wcslen(), wcscpy(), etc…) and this particular one fails.
>>
>> Please help!
>>
>>
>>
>> __________________________________
>> Yahoo! FareChase: Search multiple travel sites in one click.
>> http://farechase.yahoo.com
>>
>>
>> —
>> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
>> To unsubscribe send a blank email to
xxxxx@lists.osr.com
>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@evitechnology.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

>
>


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@evitechnology.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

> Note: I cannot use the RtlStringCbXxx functions because it would

require
rewriting a whole lot of code right now, and it’s too late in the game
for
that.

Not so. Your code does not build. What “late of the game” can this be? The code
was definitely just written. Go and replace all printf()-based functions to
StringCbPrintf or StringCchPrintf - I don’t think there are many of them.

Note: PREfast does not like the printf()-based functions at all, it mandates
StringXxPrintf - which is a good idea, since this is a buffer-overrun-related
security issue.

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

I have to concur with Max, if you are at the point of linking, you are only
at roughly 10% of the way to a solid driver. Go back fix your code, run it
with PREfast, /W4 and PC-Lint if possible, then when it is clean try to link
again.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntfsd…
>> Note: I cannot use the RtlStringCbXxx functions because it would
>> require
>> rewriting a whole lot of code right now, and it’s too late in the game
>> for
>> that.
>
> Not so. Your code does not build. What “late of the game” can this be? The
> code
> was definitely just written. Go and replace all printf()-based functions
> to
> StringCbPrintf or StringCchPrintf - I don’t think there are many of them.
>
> Note: PREfast does not like the printf()-based functions at all, it
> mandates
> StringXxPrintf - which is a good idea, since this is a
> buffer-overrun-related
> security issue.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
>

Don

You must be some ace coder! I would have thought if the driver has never
even linked he must be less than one percent through :slight_smile:

Cheers
Lyndon

“Don Burn” wrote in message news:xxxxx@ntfsd…
>I have to concur with Max, if you are at the point of linking, you are only
>at roughly 10% of the way to a solid driver. Go back fix your code, run it
>with PREfast, /W4 and PC-Lint if possible, then when it is clean try to
>link again.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
>
>
> “Maxim S. Shatskih” wrote in message
> news:xxxxx@ntfsd…
>>> Note: I cannot use the RtlStringCbXxx functions because it would
>>> require
>>> rewriting a whole lot of code right now, and it’s too late in the game
>>> for
>>> that.
>>
>> Not so. Your code does not build. What “late of the game” can this be?
>> The code
>> was definitely just written. Go and replace all printf()-based functions
>> to
>> StringCbPrintf or StringCchPrintf - I don’t think there are many of them.
>>
>> Note: PREfast does not like the printf()-based functions at all, it
>> mandates
>> StringXxPrintf - which is a good idea, since this is a
>> buffer-overrun-related
>> security issue.
>>
>> Maxim Shatskih, Windows DDK MVP
>> StorageCraft Corporation
>> xxxxx@storagecraft.com
>> http://www.storagecraft.com
>>
>>
>>
>
>
>

Lyndon,

I was trying to not completely crush his morale. Of course, if you
spend time on a solid design, use all the static analysis tools you can lay
your hands on, and are careful, I have reached the 10% point.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Lyndon J Clarke” wrote in message
news:xxxxx@ntfsd…
> Don
>
> You must be some ace coder! I would have thought if the driver has never
> even linked he must be less than one percent through :slight_smile:
>
> Cheers
> Lyndon
>
> “Don Burn” wrote in message news:xxxxx@ntfsd…
>>I have to concur with Max, if you are at the point of linking, you are
>>only at roughly 10% of the way to a solid driver. Go back fix your code,
>>run it with PREfast, /W4 and PC-Lint if possible, then when it is clean
>>try to link again.
>>
>>
>> –
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> Remove StopSpam from the email to reply
>>
>>
>>
>>
>> “Maxim S. Shatskih” wrote in message
>> news:xxxxx@ntfsd…
>>>> Note: I cannot use the RtlStringCbXxx functions because it would
>>>> require
>>>> rewriting a whole lot of code right now, and it’s too late in the game
>>>> for
>>>> that.
>>>
>>> Not so. Your code does not build. What “late of the game” can this be?
>>> The code
>>> was definitely just written. Go and replace all printf()-based functions
>>> to
>>> StringCbPrintf or StringCchPrintf - I don’t think there are many of
>>> them.
>>>
>>> Note: PREfast does not like the printf()-based functions at all, it
>>> mandates
>>> StringXxPrintf - which is a good idea, since this is a
>>> buffer-overrun-related
>>> security issue.
>>>
>>> Maxim Shatskih, Windows DDK MVP
>>> StorageCraft Corporation
>>> xxxxx@storagecraft.com
>>> http://www.storagecraft.com
>>>
>>>
>>>
>>
>>
>>
>
>
>

I am forced to convert all of my “unsafe” CRT functions to the safe variants
if I include the header that requires the RtlStringCbXxx functions.

Could you give me an example, because I’m not sure that I understand you
correctly.

“Dejan Maksimovic” wrote in message news:xxxxx@ntfsd…
>
> You can simply do a wrapper for the function you want by using the
> Rtlxxx
> functions. That will require no code rewrite, just adding a few more lines
> of code.
>
>> > Secondly, I’ve tried _vsnwprintf(), but I get the same linking errors
>> > that
>> > I get with vswprintf().
>
> –
> Kind regards, Dejan M.
> http://www.alfasp.com E-mail: xxxxx@alfasp.com
> Alfa Transparent File Encryptor - Transparent file encryption services.
> Alfa File Protector - File protection and hiding library for Win32
> developers.
> Alfa File Monitor - File monitoring library for Win32 developers.
>
>
>
>

I see that _vsnwprintf is exported by NTOSKRNL.EXE, and I’ve already tried
using it in the code (as Martin O’brien already suggested), should I be
doing any more to make this work ?

“Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
>> Secondly, I’ve tried _vsnwprintf(), but I get the same linking errors
>> that I get with vswprintf().
>
> Please, look at NTOSKRNL.EXE using DEPENDS.EXE
> and you will find which functions are exported. This will
> solve your problem faster than asking about every printf
> variant via e-mail.
>
> L.
>
>

I meant in one of your modules, do:
void vswprintf(whatever arguments)
{
RtlStringCbPrintfW();
}

I am forced to convert all of my “unsafe” CRT functions to the safe variants if I
include the header that requires the RtlStringCbXxx functions.

Could you give me an example, because I’m not sure that I understand you
correctly.


Kind regards, Dejan M.
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.

#include “strsafe.h”

or

#include “ntstrsafe.h”

one of these will work. For user-mode builds via DDK, the first one works.

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

----- Original Message -----
From: “Caleb”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Thursday, November 10, 2005 11:44 PM
Subject: Re:[ntfsd] Strange linking error when using vswprintf()

> I am forced to convert all of my “unsafe” CRT functions to the safe variants
> if I include the header that requires the RtlStringCbXxx functions.
>
> Could you give me an example, because I’m not sure that I understand you
> correctly.
>
> “Dejan Maksimovic” wrote in message news:xxxxx@ntfsd…
> >
> > You can simply do a wrapper for the function you want by using the
> > Rtlxxx
> > functions. That will require no code rewrite, just adding a few more lines
> > of code.
> >
> >> > Secondly, I’ve tried _vsnwprintf(), but I get the same linking errors
> >> > that
> >> > I get with vswprintf().
> >
> > –
> > Kind regards, Dejan M.
> > http://www.alfasp.com E-mail: xxxxx@alfasp.com
> > Alfa Transparent File Encryptor - Transparent file encryption services.
> > Alfa File Protector - File protection and hiding library for Win32
> > developers.
> > Alfa File Monitor - File monitoring library for Win32 developers.
> >
> >
> >
> >
>
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com