Strong Name Verification Failed

[Kal]

I have a small console app that started out in dotnet 1.1 in VS 2003. That
version can be copied to a W2K3 server where it runs fine.

I set up a new project in VS 2005 and copied the code files from 2003 to
2005 where they compile and run, no problem. When I copy the two files (exe
& dll) to the same W2K3 server they fail with the Strong Name Verification
Failed error. After running the console contains: "Unhandled Exception:
System.BadImageFormatException: The format of the file 'x.exe is invalid.

I tried signing the project even though MS recommends against it for simple
code like this, but it gives the same result. I tried a different W2K3
server with the same result.

I ran "sn -v x.exe" on both my XP workstation and on the failing server. In
both cases the response is: Assembly 'x.exe' is valid. The same with the
dll, which is in the directory with the dll.

Kal
..

[Kal]

Update,
On one of the W2K3 servers I have VS 2005, so I set up a copy of the project
on that machine. In debug mode under VS the project runs. The exact same
files copied to an execution directory give the same strong name
verification error.

Clearly I am missing something basic here. Anyone know where to point me in
the right direction.

Kal
"Kal" <ka*@newsgroup.nospamwrote in message
news:u6**************@TK2MSFTNGP02.phx.gbl...

>I have a small console app that started out in dotnet 1.1 in VS 2003. That
version can be copied to a W2K3 server where it runs fine.

I set up a new project in VS 2005 and copied the code files from 2003 to
2005 where they compile and run, no problem. When I copy the two files
(exe
& dll) to the same W2K3 server they fail with the Strong Name Verification
Failed error. After running the console contains: "Unhandled Exception:
System.BadImageFormatException: The format of the file 'x.exe is invalid.

I tried signing the project even though MS recommends against it for
simple
code like this, but it gives the same result. I tried a different W2K3
server with the same result.

I ran "sn -v x.exe" on both my XP workstation and on the failing server.
In
both cases the response is: Assembly 'x.exe' is valid. The same with the
dll, which is in the directory with the dll.

Kal
.

[Walter Wang [MSFT]]

Hi Kal,

I was unable to reproduce the issue you described. Here's my steps to test:

1) Create a simple console project in Visual Studio 2003 using C#, create a
key using "sn -k mykey.snk" and sign the project using this key.

2) Create another console project in Visual Studio 2005, copy the source
file and the key, sign this project using the key.

3) Copy the built assembly to another system which has .NET 2.0 Framework
installed, run it and it works correctly.

Since you've mentioned that the issue exists on another system, I think it
should be reproducible using your code. Would you please create a simple
repro project and post it here or send it to me via email? Thank you for
your effort.

Sincerely,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

[Marc Gravell]

Is it possible you are using delay signing and have disabled checking for
this assembly? Unlikely (especially at the server), but...?

[Kal]

When strong signing did not produce a better result, I disabled signing. No
options are checked. It is not needed on this project, so delay signing
seems pretty unlikely.

"Marc Gravell" <ma**********@gmail.comwrote in message
news:OM**************@TK2MSFTNGP03.phx.gbl...

Is it possible you are using delay signing and have disabled checking for
this assembly? Unlikely (especially at the server), but...?

[Kal]

Walter, thanks for your help.
The second machine has a copy of VS 2005 installed so I copied the project
there and it ran fine from within the IDE. Then I copied the two functioning
files to an execution directory where the gave the error.

I fooled with it quite a bit, including setting up an installation project,
which installed and worked on the development server. For one reason or
another I deleted that development project, recompiled, and copied the files
to the execution directory on the same machine. From that point things seem
to work there.

This morning I copied a set of files from development server to production
server where the problem originated, and they still do not work there. It is
clearly something on that server that is causing the problem.

All of these files are without strong name signing, although for a brief
period I tried it with signing.

On the production server the only thing that uses (would use) dotnet 2.0 is
this application. I believe the server has not been rebooted since the
install just prior to this series of tests; neither did it prompt to
restart. I will wait to reboot until it is essential as it is a production
machine.

I did do an extremely test project on the production server, again without
signing, and it ran fine.

Kal
"Walter Wang [MSFT]" <wa****@online.microsoft.comwrote in message
news:9P*************@TK2MSFTNGXA01.phx.gbl...

Hi Kal,

I was unable to reproduce the issue you described. Here's my steps to
test:

1) Create a simple console project in Visual Studio 2003 using C#, create
a
key using "sn -k mykey.snk" and sign the project using this key.

2) Create another console project in Visual Studio 2005, copy the source
file and the key, sign this project using the key.

3) Copy the built assembly to another system which has .NET 2.0 Framework
installed, run it and it works correctly.

Since you've mentioned that the issue exists on another system, I think it
should be reproducible using your code. Would you please create a simple
repro project and post it here or send it to me via email? Thank you for
your effort.

Sincerely,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no
rights.

[Walter Wang [MSFT]]

Hi Kal,

Thank you for your update.

To be honest, I'm not quite clear about the current status of this issue. I
must be taking too little sleep recently, :)

From your description, it seems to me that this is an environment specific
issue which only exists on your production server, right? If this is the
case, then reboot or even reinstall the .NET Framework would be a much
simpler way to try first, given that we've done some troubleshooting and it
doesn't work.

How long do you need to update here the progress? Normally we need to
update in at most two business days, so if you need more time to follow up,
please let me know. Thank you.
Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

[Kal]

Walter,
Too little sleep, is it? Maybe that is why it is confusing me too.

We will reboot in the next day or two. Reinstalling seems like a real
stretch since I installed .Net 2.0 about 5 minutes before this started to
happen.

What I am really looking for is ideas as to what kinds of thing could cause
this type of problem. But lets wait until after I can reboot and see if that
makes things work.
Kal

"Walter Wang [MSFT]" <wa****@online.microsoft.comwrote in message
news:KU*************@TK2MSFTNGXA01.phx.gbl...

Hi Kal,

Thank you for your update.

To be honest, I'm not quite clear about the current status of this issue.
I
must be taking too little sleep recently, :)

From your description, it seems to me that this is an environment specific
issue which only exists on your production server, right? If this is the
case, then reboot or even reinstall the .NET Framework would be a much
simpler way to try first, given that we've done some troubleshooting and
it
doesn't work.

How long do you need to update here the progress? Normally we need to
update in at most two business days, so if you need more time to follow
up,
please let me know. Thank you.
Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no
rights.

[Walter Wang [MSFT]]

Thanks Kal for your update.

I'll do a summary here to get a clearer picture of this issue:

1) For your production server, even without signing, an assembly built with
VS2005 will failed to pass verification.
2) The VS2005 project contains some files copied from VS2003 project; if
you build a new simple VS2005 project, it works fine.

If I'm missing something here, please feel free to tell me.

If it's not about signing, then the verification is occurred when JIT
compiler compiling MSIL to native code.

======
#Compiling MSIL to Native Code
http://msdn2.microsoft.com/en-us/library/ht8ecch6.aspx
As part of compiling MSIL to native code, code must pass a verification
process unless an administrator has established a security policy that
allows code to bypass verification. Verification examines MSIL and metadata
to find out whether the code is tyep safe, which means that it only
accesses the memory locations it is authorized to access.
======

You can verify your code by using PEVerify:

======
#PEVerify Tool (Peverify.exe)
http://msdn2.microsoft.com/en-us/library/62bwd2yd.aspx
The PEVerify tool helps determine whether MSIL code and associated metadata
meet type safetype requiretments.
======

Please tell me the result of PEVerify.exe. Also, is it possible to create a
small reproducible project and send it to me so that I can test it? Thank
you.

By the way, if this issue is urgent and critical for your business, due to
the nature of such problem, I suggest you contact PSS for further
assistance which will provide some thorough throubleshooting like dump
analyze or live debugging.

For PSS support or a local on site, you can also try contacting the global
support center through the following link:

http://support.microsoft.com/gp/assistsupport

They will provide you the detailed info on how to contact the local
developer support center.

Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

[Kal]

Walter,
Thanks for your help. This item is not critical because the VS2003 code
still works. I do plan to make some changes that will possibly be 2.0
specific, so want to get this working, but it is not a top priority.

Since last I wrote I have restarted the server with no improvement, and also
reinstalled dotnet 2.0.

On the compile machine:
Microsoft (R) .NET Framework PE Verifier. Version 2.0.50727.42
All Classes and Methods in rssDailyGen.exe Verified.
And on the problem server:
D:\Program Files\ECBridge\RSSCreate\RssDailyGen>peverify RssDailyGen.exe /md
/il /clock

Microsoft (R) .NET Framework PE Verifier. Version 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.

All Classes and Methods in RssDailyGen.exe Verified.
Timing: Total run 218 msec
MD Val.cycle 31 msec
MD Val.pure 16 msec
IL Ver.cycle 187 msec
IL Ver.pure 171 msec

So that does not seem to be the problem.

I am beginning to think it may not be the VS2003 code because there is
nothing very complex nor sophisticated there. I extract some records from a
SQL 2000 database, and for each record do some verification and edititng and
then write an RSS 2.0 XML file with each record becoming a node via
XmlTextWriter. The connection string is in the config file and various other
parameters are in a second xml file that gets called from the command line.
These configuration files are specific to the installation rather than to
the exe, so they are not changed when I copy in a new version exe and dll.

Kal
"Walter Wang [MSFT]" <wa****@online.microsoft.comwrote in message
news:Ed**************@TK2MSFTNGXA01.phx.gbl...

Thanks Kal for your update.

I'll do a summary here to get a clearer picture of this issue:

1) For your production server, even without signing, an assembly built
with
VS2005 will failed to pass verification.
2) The VS2005 project contains some files copied from VS2003 project; if
you build a new simple VS2005 project, it works fine.

If I'm missing something here, please feel free to tell me.

If it's not about signing, then the verification is occurred when JIT
compiler compiling MSIL to native code.

======
#Compiling MSIL to Native Code
http://msdn2.microsoft.com/en-us/library/ht8ecch6.aspx
As part of compiling MSIL to native code, code must pass a verification
process unless an administrator has established a security policy that
allows code to bypass verification. Verification examines MSIL and
metadata
to find out whether the code is tyep safe, which means that it only
accesses the memory locations it is authorized to access.
======

You can verify your code by using PEVerify:

======
#PEVerify Tool (Peverify.exe)
http://msdn2.microsoft.com/en-us/library/62bwd2yd.aspx
The PEVerify tool helps determine whether MSIL code and associated
metadata
meet type safetype requiretments.
======

Please tell me the result of PEVerify.exe. Also, is it possible to create
a
small reproducible project and send it to me so that I can test it? Thank
you.

By the way, if this issue is urgent and critical for your business, due to
the nature of such problem, I suggest you contact PSS for further
assistance which will provide some thorough throubleshooting like dump
analyze or live debugging.

For PSS support or a local on site, you can also try contacting the global
support center through the following link:

http://support.microsoft.com/gp/assistsupport

They will provide you the detailed info on how to contact the local
developer support center.

Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no
rights.

[Walter Wang [MSFT]]

Hi Kal,

Thanks for the update. I'm sorry I cannot provide more support here in
Newsgroup Support. However, if you're interested, you may try to use WinDbg
to debug the application on your production server.

1. Download Debugging Tools For Windows from
http://www.microsoft.com/whdc/devtoo...g/default.mspx, install it
on your production server
2. Compile your application with debug information; copy the .exe and .pdb
file to your production server
3. Start WinDbg, select menu "File/Open Executable..." and load your .exe
4. At the prompt of WinDbg, type ".load
C:\\WINDOWS\\Microsoft.NET\\Framework\\v2.0.50727\ \SOS.dll" to load an
extension which enables you to debug .NET application in WinDbg efficiently
5. Type "g" in WinDbg to continue your application, when it failed, type
command "!clrstack" to view the stack.

#WinDbg / SOS Cheat Sheet
http://geekswithblogs.net/.netonmymi.../14/72262.aspx

#Production Debugging for .NET Framework Applications
http://msdn.microsoft.com/library/de...us/dnbda/html/
DBGrm.asp

Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

[Kal]

Walter,
I did those steps, but have not yet installed the symbol files for
Windows/.net. WinDbg did not give a stack list due to no symbol files found.
Was it looking for my pdb files or the downloaded symbol files? My pdb files
are in the executable directory.

I did see a couple of first level and one second level exceptions.

What will I be looking for in that stack list that might be the key?
Kal
"Walter Wang [MSFT]" <wa****@online.microsoft.comwrote in message
news:Gg*************@TK2MSFTNGXA01.phx.gbl...

Hi Kal,

Thanks for the update. I'm sorry I cannot provide more support here in
Newsgroup Support. However, if you're interested, you may try to use
WinDbg
to debug the application on your production server.

1. Download Debugging Tools For Windows from
http://www.microsoft.com/whdc/devtoo...g/default.mspx, install it
on your production server
2. Compile your application with debug information; copy the .exe and .pdb
file to your production server
3. Start WinDbg, select menu "File/Open Executable..." and load your .exe
4. At the prompt of WinDbg, type ".load
C:\\WINDOWS\\Microsoft.NET\\Framework\\v2.0.50727\ \SOS.dll" to load an
extension which enables you to debug .NET application in WinDbg
efficiently
5. Type "g" in WinDbg to continue your application, when it failed, type
command "!clrstack" to view the stack.

#WinDbg / SOS Cheat Sheet
http://geekswithblogs.net/.netonmymi.../14/72262.aspx

#Production Debugging for .NET Framework Applications
http://msdn.microsoft.com/library/de...us/dnbda/html/
DBGrm.asp

Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no
rights.

[Walter Wang [MSFT]]

Hi Kal,

Your pdb file should be ok if it's in the same directory as your executable.

You need to setup WinDbg to use Microsoft Symbol Server as described at
http://www.microsoft.com/whdc/devtoo...ebugstart.mspx

As a second thought, in this case, since it's not your .NET application
throws exception, we actually don't need to use the SOS extension for
WinDbg as I described.

After you setup the symbol, load your application:
1) Type 'g' to run the application
2) When it is stopped since exception is thrown, type 'k' to get the stack
trace.

After you get the stack trace, you may post it here or send it to me.

Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

[Kal]

Walter,
Thanks for your help. WinDbg provided the clue, which once noted made the
solution obvious.

The exe.config file had an artifact, namely:
<startup>
<supportedRuntime version="v1.1.4322" />
</startup>

When replaced by the correct information it runs just fine.
Kal
"Walter Wang [MSFT]" <wa****@online.microsoft.comwrote in message
news:A4**************@TK2MSFTNGXA01.phx.gbl...

Hi Kal,

Your pdb file should be ok if it's in the same directory as your
executable.

You need to setup WinDbg to use Microsoft Symbol Server as described at
http://www.microsoft.com/whdc/devtoo...ebugstart.mspx

As a second thought, in this case, since it's not your .NET application
throws exception, we actually don't need to use the SOS extension for
WinDbg as I described.

After you setup the symbol, load your application:
1) Type 'g' to run the application
2) When it is stopped since exception is thrown, type 'k' to get the stack
trace.

After you get the stack trace, you may post it here or send it to me.

Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no
rights.