Hi;

When we install our program on Vista, it won't run. It does run fine
on XP and so we're guessing that it is some kind of
security/permission issue. This is on a 64-bit system.

The program is installed under Program Files. The DLLs it uses (19 of
them) are installed in the GAC. The program is a C# program and it
starts. The log4j.dll is the first method in any of our DLLs that it
calls. log4j is a J# project.

Does anyone have any idea what is going on?

thanks - dave 

Here’s the dump from the command line:

Unhandled Exception: System.IO.FileNotFoundException: Could not load
file or assembly 'log4j, Version=1.2.12.0, Culture=neutral,
PublicKeyToken=a03dd7a39948a7d3' or one of its dependencies. The
system cannot find the file specified.

File name: 'log4j, Version=1.2.12.0, Culture=neutral,
PublicKeyToken=a03dd7a39948a7d3'
   at net.windward.samples.RunReport.Main(String[] args)

=== Pre-bind state information ===
LOG: User = Intern1\mikeg
LOG: DisplayName = log4j, Version=1.2.12.0, Culture=neutral,
PublicKeyToken=a03dd7a39948a7d3

 (Fully-specified)

LOG: Appbase = file:///C:/Users/mikeg/Documents/

LOG: Initial PrivatePath = NULL

Calling assembly : RunReport, Version=6.1.3.2, Culture=neutral,
PublicKeyToken=cddbfa18b979fa34.

===

LOG: This bind starts in default load context.

LOG: Using application configuration file:
C:\Users\mikeg\Documents\RunReport.exe.config

LOG: Using machine configuration file from
C:\Windows\Microsoft.NET\Framework64\

v2.0.50727\config\machine.config.

LOG: Post-policy reference: log4j, Version=1.2.12.0, Culture=neutral,
PublicKeyToken=a03dd7a39948a7d3

LOG: The same bind was seen before, and was failed with hr =
0x80070002.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Ran again and got:

Unhandled Exception: System.BadImageFormatException: Could not load
file or asse

mbly 'log4j, Version=1.2.12.0, Culture=neutral,
PublicKeyToken=a03dd7a39948a7d3'

 or one of its dependencies. An attempt was made to load a program
with an incor

rect format.

File name: 'log4j, Version=1.2.12.0, Culture=neutral,
PublicKeyToken=a03dd7a3994

8a7d3'

   at net.windward.samples.RunReport.Main(String[] args)

 

=== Pre-bind state information ===

LOG: User = Intern1\mikeg

LOG: DisplayName = log4j, Version=1.2.12.0, Culture=neutral,
PublicKeyToken=a03d

d7a39948a7d3

 (Fully-specified)

LOG: Appbase = file:///C:/Users/mikeg/Documents/

LOG: Initial PrivatePath = NULL

Calling assembly : RunReport, Version=6.1.3.2, Culture=neutral,
PublicKeyToken=c

ddbfa18b979fa34.

===

LOG: This bind starts in default load context.

LOG: Using application configuration file:
C:\Users\mikeg\Documents\RunReport.ex

e.config

LOG: Using machine configuration file from
C:\Windows\Microsoft.NET\Framework64\

v2.0.50727\config\machine.config.

LOG: Post-policy reference: log4j, Version=1.2.12.0, Culture=neutral,
PublicKeyT

oken=a03dd7a39948a7d3

LOG: Attempting download of new URL
file:///C:/Users/mikeg/Documents/log4j.DLL.

ERR: Failed to complete setup of assembly (hr = 0x8007000b). Probing
terminated.



david@at-at-at@windward.dot.dot.net
Windward Reports -- http://www.WindwardReports.com
me -- http://dave.thielen.com

Cubicle Wars - http://www.windwardreports.com/film.htm

David Thielen wrote:
> Hi;
>
> When we install our program on Vista, it won't run. It does run fine
> on XP and so we're guessing that it is some kind of
> security/permission issue. This is on a 64-bit system.
>
> The program is installed under Program Files. The DLLs it uses (19 of
> them) are installed in the GAC. The program is a C# program and it
> starts. The log4j.dll is the first method in any of our DLLs that it
> calls. log4j is a J# project.
>
> Does anyone have any idea what is going on?

As a first guess, your main program is marked machine-independent (target 
platform = MSIL), so it loads with the preferred (64-bit) runtime, but one 
of your libraries is 32-bit only.  Quick fix is to mark the main .exe as 
32-bit (target platform = x86) when you build it.

>
> thanks - dave
>
> Here's the dump from the command line:
>
> Unhandled Exception: System.IO.FileNotFoundException: Could not load
> file or assembly 'log4j, Version=1.2.12.0, Culture=neutral,
> PublicKeyToken=a03dd7a39948a7d3' or one of its dependencies. The
> system cannot find the file specified.
>
> File name: 'log4j, Version=1.2.12.0, Culture=neutral,
> PublicKeyToken=a03dd7a39948a7d3'
>   at net.windward.samples.RunReport.Main(String[] args)
>
> === Pre-bind state information ===
> LOG: User = Intern1\mikeg
> LOG: DisplayName = log4j, Version=1.2.12.0, Culture=neutral,
> PublicKeyToken=a03dd7a39948a7d3
>
> (Fully-specified)
>
> LOG: Appbase = file:///C:/Users/mikeg/Documents/
>
> LOG: Initial PrivatePath = NULL
>
> Calling assembly : RunReport, Version=6.1.3.2, Culture=neutral,
> PublicKeyToken=cddbfa18b979fa34.
>
> ===
>
> LOG: This bind starts in default load context.
>
> LOG: Using application configuration file:
> C:\Users\mikeg\Documents\RunReport.exe.config
>
> LOG: Using machine configuration file from
> C:\Windows\Microsoft.NET\Framework64\
>
> v2.0.50727\config\machine.config.
>
> LOG: Post-policy reference: log4j, Version=1.2.12.0, Culture=neutral,
> PublicKeyToken=a03dd7a39948a7d3
>
> LOG: The same bind was seen before, and was failed with hr =
> 0x80070002.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Ran again and got:
>
> Unhandled Exception: System.BadImageFormatException: Could not load
> file or asse
>
> mbly 'log4j, Version=1.2.12.0, Culture=neutral,
> PublicKeyToken=a03dd7a39948a7d3'
>
> or one of its dependencies. An attempt was made to load a program
> with an incor
>
> rect format.
>
> File name: 'log4j, Version=1.2.12.0, Culture=neutral,
> PublicKeyToken=a03dd7a3994
>
> 8a7d3'
>
>   at net.windward.samples.RunReport.Main(String[] args)
>
>
>
> === Pre-bind state information ===
>
> LOG: User = Intern1\mikeg
>
> LOG: DisplayName = log4j, Version=1.2.12.0, Culture=neutral,
> PublicKeyToken=a03d
>
> d7a39948a7d3
>
> (Fully-specified)
>
> LOG: Appbase = file:///C:/Users/mikeg/Documents/
>
> LOG: Initial PrivatePath = NULL
>
> Calling assembly : RunReport, Version=6.1.3.2, Culture=neutral,
> PublicKeyToken=c
>
> ddbfa18b979fa34.
>
> ===
>
> LOG: This bind starts in default load context.
>
> LOG: Using application configuration file:
> C:\Users\mikeg\Documents\RunReport.ex
>
> e.config
>
> LOG: Using machine configuration file from
> C:\Windows\Microsoft.NET\Framework64\
>
> v2.0.50727\config\machine.config.
>
> LOG: Post-policy reference: log4j, Version=1.2.12.0, Culture=neutral,
> PublicKeyT
>
> oken=a03dd7a39948a7d3
>
> LOG: Attempting download of new URL
> file:///C:/Users/mikeg/Documents/log4j.DLL.
>
> ERR: Failed to complete setup of assembly (hr = 0x8007000b). Probing
> terminated.
>
>
>
> david@at-at-at@windward.dot.dot.net
> Windward Reports -- http://www.WindwardReports.com
> me -- http://dave.thielen.com
>
> Cubicle Wars - http://www.windwardreports.com/film.htm

Bingo - J# appears to be 32-bit only. THANK YOU.

ps - would it kill Microsoft to actually have useful error messages???



On Wed, 21 May 2008 17:03:23 -0500, "Ben Voigt [C++ MVP]"
<rbv@nospam.nospam> wrote:

>David Thielen wrote:
>> Hi;
>>
>> When we install our program on Vista, it won't run. It does run fine
>> on XP and so we're guessing that it is some kind of
>> security/permission issue. This is on a 64-bit system.
>>
>> The program is installed under Program Files. The DLLs it uses (19 of
>> them) are installed in the GAC. The program is a C# program and it
>> starts. The log4j.dll is the first method in any of our DLLs that it
>> calls. log4j is a J# project.
>>
>> Does anyone have any idea what is going on?
>
>As a first guess, your main program is marked machine-independent (target 
>platform = MSIL), so it loads with the preferred (64-bit) runtime, but one 
>of your libraries is 32-bit only.  Quick fix is to mark the main .exe as 
>32-bit (target platform = x86) when you build it.

>> LOG: Using machine configuration file from
>> C:\Windows\Microsoft.NET\Framework64\
>>
>> v2.0.50727\config\machine.config.
>>
>> LOG: Post-policy reference: log4j, Version=1.2.12.0, Culture=neutral,
>> PublicKeyT
>>
>> oken=a03dd7a39948a7d3
>>
>> LOG: Attempting download of new URL
>> file:///C:/Users/mikeg/Documents/log4j.DLL.
>>
>> ERR: Failed to complete setup of assembly (hr = 0x8007000b). Probing
>> terminated.
>>
>>
>>
>> david@at-at-at@windward.dot.dot.net
>> Windward Reports -- http://www.WindwardReports.com
>> me -- http://dave.thielen.com
>>
>> Cubicle Wars - http://www.windwardreports.com/film.htm 
>


david@at-at-at@windward.dot.dot.net
Windward Reports -- http://www.WindwardReports.com
me -- http://dave.thielen.com

Cubicle Wars - http://www.windwardreports.com/film.htm

Hi David ,

Does this problem occur in a 32-bit Vista machine? I recommend you to test 
it on the 32bit Vista. This will help us to isolate if this problem is 
64bit Vista specific. 

If it also fails on the 32bit Vista, it may be caused by the security 
enhancement feature of Vista, such as UAC, Virtualization etc..

An informative approach to troubleshoot the FileNotFoundException is using 
the Process Monitor. You may add a filter for your process name and notice 
any records with "Not Found". The ProcMon records will reveal the CLR 
loader probing paths. You may download the Process Monitor from the link 
below:
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx?PHPSESSID=d926

Also, have you tried to turn-on the Fusion log for analysis? See the 
article below more details:
"Debugging Assembly Loading Failures"
http://blogs.msdn.com/suzcook/archive/2003/05/29/57120.aspx

Hope it helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and 
suggestions about how we can improve the support we provide to you. Please 
feel free to let my manager know what you think of the level of service 
provided. You can send feedback directly to my manager at: 
msdnmg@microsoft.com.

==================================================
Get notification to my posts through email? Please refer to 
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.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/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Hi David,

Actually, it is hard for me to believe this is caused by the 32bitness of 
the J# assembly. As I know there is no bitness for .Net assemblies. The 
code in the .Net assembly is always MSIL, and the CLR is responsible to 
translate the MSIL code into the corresponding binary code 32bit or 64bit 
depending on the target CLR and platform. This is main goal of .Net/MSIL to 
achieve platform independent. 

Yes, the compiler may emit a 32bit PE file for compatibility reason, 
however, the CLR will ignore it and generate the corresponding binary code. 
So the bitness of the .Net assembly should not cause any problem. The 
bitness of CLR matters. 

Anyway, without reproducing this problem, it is hard for me to say the root 
cause or understand. If I have misunderstood anything, please feel free to 
tell me, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
=========================================
Delighting our customers is our #1 priority. We welcome your comments and 
suggestions about how we can improve the support we provide to you. Please 
feel free to let my manager know what you think of the level of service 
provided. You can send feedback directly to my manager at: 
msdnmg@microsoft.com.

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

Hi;

That is it. We are working on getting the 64-bit J#. There are
instructions on where to download the runtimes, but none on where the
compiler is.

thanks - dave


On Thu, 22 May 2008 08:39:32 GMT, jetan@online.microsoft.com ("Jeffrey
Tan[MSFT]") wrote:

>Hi David,
>
>Actually, it is hard for me to believe this is caused by the 32bitness of 
>the J# assembly. As I know there is no bitness for .Net assemblies. The 
>code in the .Net assembly is always MSIL, and the CLR is responsible to 
>translate the MSIL code into the corresponding binary code 32bit or 64bit 
>depending on the target CLR and platform. This is main goal of .Net/MSIL to 
>achieve platform independent. 
>
>Yes, the compiler may emit a 32bit PE file for compatibility reason, 
>however, the CLR will ignore it and generate the corresponding binary code. 
>So the bitness of the .Net assembly should not cause any problem. The 
>bitness of CLR matters. 
>
>Anyway, without reproducing this problem, it is hard for me to say the root 
>cause or understand. If I have misunderstood anything, please feel free to 
>tell me, thanks.
>
>Best regards,
>Jeffrey Tan
>Microsoft Online Community Support
>=========================================
>Delighting our customers is our #1 priority. We welcome your comments and 
>suggestions about how we can improve the support we provide to you. Please 
>feel free to let my manager know what you think of the level of service 
>provided. You can send feedback directly to my manager at: 
>msdnmg@microsoft.com.
>
>This posting is provided "AS IS" with no warranties, and confers no rights.


david@at-at-at@windward.dot.dot.net
Windward Reports -- http://www.WindwardReports.com
me -- http://dave.thielen.com

Cubicle Wars - http://www.windwardreports.com/film.htm

Hi Dave,

Sorry, I am not sure if I understand you completely. I am not an expert on 
the J#, but since it is .Net based, the compiler should emit MSIL code in 
the generated assembly. Once it runs on the 64bit CLR and OS, the 64bit CLR 
will translate the MSIL code into 64bit binary code. Can you help to 
explain your current problem or confusion in details? Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
=========================================
Delighting our customers is our #1 priority. We welcome your comments and 
suggestions about how we can improve the support we provide to you. Please 
feel free to let my manager know what you think of the level of service 
provided. You can send feedback directly to my manager at: 
msdnmg@microsoft.com.

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

Hi;

I don't understand either what/why. But I do know it works if we force
everything to 32-bit. We're downloading the new J# 2.0 and it supports
64-bit so that may resolve this.

thanks - dave


On Fri, 23 May 2008 06:23:23 GMT, jetan@online.microsoft.com ("Jeffrey
Tan[MSFT]") wrote:

>Hi Dave,
>
>Sorry, I am not sure if I understand you completely. I am not an expert on 
>the J#, but since it is .Net based, the compiler should emit MSIL code in 
>the generated assembly. Once it runs on the 64bit CLR and OS, the 64bit CLR 
>will translate the MSIL code into 64bit binary code. Can you help to 
>explain your current problem or confusion in details? Thanks.
>
>Best regards,
>Jeffrey Tan
>Microsoft Online Community Support
>=========================================
>Delighting our customers is our #1 priority. We welcome your comments and 
>suggestions about how we can improve the support we provide to you. Please 
>feel free to let my manager know what you think of the level of service 
>provided. You can send feedback directly to my manager at: 
>msdnmg@microsoft.com.
>
>This posting is provided "AS IS" with no warranties, and confers no rights.


david@at-at-at@windward.dot.dot.net
Windward Reports -- http://www.WindwardReports.com
me -- http://dave.thielen.com

Cubicle Wars - http://www.windwardreports.com/film.htm

Hi David ,

Thanks for your clarification.

Ok, if you need any further help, please feel free to feedback, I will work 
with you. Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
=========================================
Delighting our customers is our #1 priority. We welcome your comments and 
suggestions about how we can improve the support we provide to you. Please 
feel free to let my manager know what you think of the level of service 
provided. You can send feedback directly to my manager at: 
msdnmg@microsoft.com.

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

"Jeffrey Tan[MSFT]" wrote:
> Hi David,
>
> Actually, it is hard for me to believe this is caused by the
> 32bitness of the J# assembly. As I know there is no bitness for .Net
> assemblies. The code in the .Net assembly is always MSIL, and the CLR
> is responsible to translate the MSIL code into the corresponding
> binary code 32bit or 64bit depending on the target CLR and platform.
> This is main goal of .Net/MSIL to achieve platform independent.
>
> Yes, the compiler may emit a 32bit PE file for compatibility reason,
> however, the CLR will ignore it and generate the corresponding binary
> code. So the bitness of the .Net assembly should not cause any
> problem. The bitness of CLR matters.


Mixed-mode assemblies generated by the C++/CLI compiler?  P/invoke?

Your points may be true about the specific J# runtime support DLLs but 
aren't true of .NET assemblies in general, nor the native DLLs they call 
into.

There most certainly are a significant number of .NET applications which 
fail due to bitness mismatches in an environment where the 64-bit CLR is 
configured as default.


>
> Anyway, without reproducing this problem, it is hard for me to say
> the root cause or understand. If I have misunderstood anything,
> please feel free to tell me, thanks.
>
> Best regards,
> Jeffrey Tan
> Microsoft Online Community Support
> =========================================
> Delighting our customers is our #1 priority. We welcome your comments
> and suggestions about how we can improve the support we provide to
> you. Please feel free to let my manager know what you think of the
> level of service provided. You can send feedback directly to my
> manager at: msdnmg@microsoft.com.
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.

Hi Ben,

Thanks for your feedback.

No, this does not apply to mixed-mode assembly or native DLL. Mixed mode 
assembly may contain the machine dependent code, so its bitness might 
matter. I mean the pure managed code .Net assembly, including, C#, J#, 
VB.net etc...

Based on my experience, on 64bit OS, the 64bit CLR will JIT the 32bit 
assembly's code into the 64bit binary code. I think this is the machine 
independent principle of .Net. If I got it incorrect, please feel free to 
tell me. Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
=========================================
Delighting our customers is our #1 priority. We welcome your comments and 
suggestions about how we can improve the support we provide to you. Please 
feel free to let my manager know what you think of the level of service 
provided. You can send feedback directly to my manager at: 
msdnmg@microsoft.com.

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

"Jeffrey Tan[MSFT]" wrote:
> Hi Ben,
>
> Thanks for your feedback.
>
> No, this does not apply to mixed-mode assembly or native DLL. Mixed
> mode assembly may contain the machine dependent code, so its bitness
> might matter. I mean the pure managed code .Net assembly, including,
> C#, J#, VB.net etc...
>
> Based on my experience, on 64bit OS, the 64bit CLR will JIT the 32bit
> assembly's code into the 64bit binary code. I think this is the

Only if the assembly is
(1) pure MSIL
and
(2) marked MSIL, not marked x86 or amd64 (in the .NET metadata, I think the 
PE header might still contain a 32-bit marking)

> machine independent principle of .Net. If I got it incorrect, please
> feel free to tell me. Thanks.
>
> Best regards,
> Jeffrey Tan
> Microsoft Online Community Support
> =========================================
> Delighting our customers is our #1 priority. We welcome your comments
> and suggestions about how we can improve the support we provide to
> you. Please feel free to let my manager know what you think of the
> level of service provided. You can send feedback directly to my
> manager at: msdnmg@microsoft.com.
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.

Hi Ben,

Thanks for the clarification.

I did not have 64bit OS on my hand now. I will perform a deeper research 
and confirmation in future. I do know that if we choose "Any CPU" in the C# 
compiler, the compiler will emit a .Net assembly with 32bit PE header. 

Thanks for your help in the community.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
=========================================
Delighting our customers is our #1 priority. We welcome your comments and 
suggestions about how we can improve the support we provide to you. Please 
feel free to let my manager know what you think of the level of service 
provided. You can send feedback directly to my manager at: 
msdnmg@microsoft.com.

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

""Jeffrey Tan[MSFT]"" wrote:

> Hi David ,
> 
> Does this problem occur in a 32-bit Vista machine? I recommend you to test 
> it on the 32bit Vista. This will help us to isolate if this problem is 
> 64bit Vista specific. 
> 
> If it also fails on the 32bit Vista, it may be caused by the security 
> enhancement feature of Vista, such as UAC, Virtualization etc..
> 
> An informative approach to troubleshoot the FileNotFoundException is using 
> the Process Monitor. You may add a filter for your process name and notice 
> any records with "Not Found". The ProcMon records will reveal the CLR 
> loader probing paths. You may download the Process Monitor from the link 
> below:
> http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx?PHPSESSID=d926
> 
> Also, have you tried to turn-on the Fusion log for analysis? See the 
> article below more details:
> "Debugging Assembly Loading Failures"
> http://blogs.msdn.com/suzcook/archive/2003/05/29/57120.aspx
> 
> Hope it helps.
> 
> Best regards,
> Jeffrey Tan
> Microsoft Online Community Support
> 
> Delighting our customers is our #1 priority. We welcome your comments and 
> suggestions about how we can improve the support we provide to you. Please 
> feel free to let my manager know what you think of the level of service 
> provided. You can send feedback directly to my manager at: 
> msdnmg@microsoft.com.
> 
> ==================================================
> Get notification to my posts through email? Please refer to 
> http://msdn.microsoft.com/subscriptions/managednewsgroups/default.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/subscriptions/support/default.aspx.
> ==================================================
> This posting is provided "AS IS" with no warranties, and confers no rights.
> 
>