Unable to run latest code -- any ideas?

Topics: CAB & Smart Client Software Factory
Jun 28, 2005 at 4:25 AM
originally posted by: GretchenSmith

I successfully worked with the first drop of CAB. This time I cannot run any part without throwing an exception similar to this:

System.BadImageFormatException was unhandled
Message="An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)"
Source="Microsoft.Practices.ComponentModel"
StackTrace:
at Microsoft.Practices.ComponentModel.CompositeContainer.CreateT(String name)
at BankTellerShell.Program.Main() in C:\Documents and Settings\gretchen.smith\My Documents\Visual Studio 2005\Projects\CompositeUIBlock\CAB\QuickStarts\BankTeller\BankTellerShell\Program.cs:line 31
at System.AppDomain.nExecuteAssembly(Assembly assembly, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()

My configuration has changed as I am now running XP 64, Beta2 build of VS2005. Other compilations of my own projects work fine so far.

Creating a MainWorkItem is where it fails:

static void Main()
{
Host = new ApplicationHostFactory().CreateHost();
--> MainWorkItem mainWorkItem = Host.Create<MainWorkItem>("main");

Any help or comments appreciated. I am running as administrator on this box so I don't think it is security related.

Thanks
Jun 28, 2005 at 8:21 AM
originally posted by: PProvost

I must apologize for this answer, but I'm not running x64 yet, so...

When you create a new Windows Forms project on your machine, and compare the system references to those in our projects, are they pointing to the same assemblies?
Jun 28, 2005 at 9:54 AM
originally posted by: GretchenSmith

References point to C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215\System.dll etc.
They match my own project using Windows Forms which does run.

I also tried this on my co-worker's x64 with the same results. Neither computer is able to run any of the Quick Starts.

Impatient to try the new stuff, looks like it's going to be fun!
Jun 30, 2005 at 1:25 PM
originally posted by: PProvost

Gretchen,

I wanted to follow-up with you on this...

The problem is that the main entry point is loading up under the 64-bit CLR, but then an assembly later on is trying to load up that was compiled with the x86 flag set (as opposed to the "Any CPU" flag).

I'm trying to track it down further to figure out which one it is, but I wanted to let you know what I've learned so far.

Thanks again for your support and patience.

--Peter
Jul 1, 2005 at 5:57 AM
originally posted by: PProvost

OK. I've run my tests. I got an IA64 machine running 64-bit Windows 2003 Server.

I installed VS2005 Beta 2, XCOPY deployed NUnit 2.1.4 and installed NUnit.Framework.dll into the GAC.

The project compiles fine. NUnit GUI runs the unit tests just fine.

I then exited out of Visual Studio and ran the Bank Teller application (BankShell.exe).

It ran fine and I confirmed by looking the Task Manager that it was running as a 64-bit process. (Look for the *32 next to 32-bit processes.)

I then went back into Visual Studio and pressed F5 (Start w/ Debugger). The Bank Teller came up just fine.

FYI, I did all of this on the current codebase that we will be posting today or tomorrow. But I don't think this is relevant. We haven't changed any of these compile options.

So...

Until you can get the new code, here is something I'd like you to try:

Before get it to fail the way you described above:
- Launch "fuslogvw.exe"
- Click "Settings", choose "Log bind failures to disk"
- Click OK.

With Fuslogvw still running, make it fail. The in fuslogwv, click "Refresh". You should now be able to figure out which assembly is failing to load.

That assembly is probably either a 1.1 framework assembly or it is a 2.0 assembly that was compiled in x86 mode.

Let me know what you learn.
Jul 1, 2005 at 6:56 AM
originally posted by: GretchenSmith

I am not sure what I am getting. I only get Native Image errors, I do not get 'default' errors. If I change to log all bindings I will get log items for default. I have the native image errors zipped up if anyone wants to look at them. these assemblies have errors

BankShell.exe
BankShell.vhost.exe
CompositeUI
COmpositeUI.WinForms
ComponentModel
ComponentModel.resources
Microsoft.VisualStudio.HostingProcess.Utilities
Microsoft.VisualStudio.HostingProcess.Utilities.sync


They are all similar to

      • Assembly Binder Log Entry (6/30/2005 @ 12:40:56 PM) ***

The operation failed.
Bind result: hr = 0x80070002. The system cannot find the file specified.

Assembly manager loaded from: C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50215\mscorwks.dll
Running under executable C:\Documents and Settings\gretchen.smith\My Documents\Visual Studio 2005\Projects\CompositeUIBlock\CAB\QuickStarts\BankTeller\BankTellerShell\bin\Debug\BankTellerShell.vshost.exe
--- A detailed error log follows.

=== Pre-bind state information ===
LOG: User = IMPACT\gretchen.smith
LOG: DisplayName = Microsoft.VisualStudio.HostingProcess.Utilities.Sync, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
(Fully-specified)
LOG: Appbase = file:///C:/Documents and Settings/gretchen.smith/My Documents/Visual Studio 2005/Projects/CompositeUIBlock/CAB/QuickStarts/BankTeller/BankTellerShell/bin/Debug/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = BankTellerShell.vshost.exe
Calling assembly : Microsoft.VisualStudio.HostingProcess.Utilities, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
===
LOG: Start binding of native image Microsoft.VisualStudio.HostingProcess.Utilities.Sync, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
WRN: No matching native image found.


NUnit GUI also complains loudly BadImageFormatException for ComponentModel.Tests -- format is invalid.

Definitely out of my range of expertise!

Thanks
Jul 1, 2005 at 7:16 AM
originally posted by: PProvost

OK. Let's try something else.

Try going into all of the projects' settings and changing them to x86 (yes I mean x86) as the Target Platform.

That will force everything to run in a WOW layer.

Let's see what that does.
Jul 1, 2005 at 7:24 AM
originally posted by: BradWilsonMSFT

It looks like maybe there's a problem with Visual Studio. The thing that failed to bind is a Visual Studio DLL. Painful as it sounds, have you tried reinstalling Visual Studio? Or, is there a co-worker running x64 Visual Studio who can also reproduce this issue? (Assuming you guys don't share a common install image like a Virtual PC image...)
Jul 1, 2005 at 7:36 AM
originally posted by: PProvost

Brad's got an interesting point there.

What version of VS are you running? Are you running a 64-bit version or a 32-bit version?

FWIW, I was running a 32-bit version on an IA-64 machine. It happily generated a platform agnostic assembly that ran as a 64-bit process.

I'm wondering if this is just a bug in the 64-bit version of VS. If you tell me which one, I'll see if I can get a machine and repro.

Also, if you are running 64-bit VS, are you on an x64 or an IA64 architecture?
Jul 1, 2005 at 7:41 AM
originally posted by: GretchenSmith

Yes, it is reproducible. One other co-worker has x64 installed and I was able to duplicate the problem there before I posted.

Definitely not the same image (no VPC involved). My setup is a pretty clean one, new hard disk and new OS XP x64 (not server) and applied all autoupdates to date, fresh install of VS2005 9.0.50215.44 beta2.050215-4400. .NET Framework 2.0.50215.

I used the VS disks from TechNet, he used the monthly MSDN shipment to do his. I doubt my install of VS2005 is the problem.

VS2003 is not installed, however .NET framework 1.1.4322 is installed.
Jul 1, 2005 at 7:44 AM
originally posted by: PProvost

So can I assume that you have a 32-bit version of Beta 2 installed then? (I can't tell from that version number.)

Also, on my machine, I did NOT have 1.1.4322 installed. I wonder if that makes a difference. (It shouldn't I know, but at this point we're all just swinging in the dark.)
Jul 1, 2005 at 7:47 AM
originally posted by: GretchenSmith

I assume it's 32 bit since it shows up with the as devenv.exe *32. The last post I did has the Builds for VS2005 and .NET framework.

Here is my system info:
OS Name Microsoft(R) Windows(R) XP Professional x64 Edition
Version 5.2.3790 Service Pack 1 Build 3790
OS Manufacturer Microsoft Corporation
System Name IMPACT-GSMITH
System Type x64-based PC
Processor AMD64 Family 15 Model 4 Stepping 8 AuthenticAMD ~2003 Mhz
BIOS Version/Date American Megatrends Inc. 1002.007, 8/21/2003
SMBIOS Version 2.3
Windows Directory C:\WINDOWS
System Directory C:\WINDOWS\system32
Boot Device \Device\HarddiskVolume1
Locale United States
Hardware Abstraction Layer Version = "5.2.3790.1830 (srv03sp1rtm.050324-1447)"
User Name IMPACT\gretchen.smith
Time Zone Eastern Daylight Time
Total Physical Memory 1,534.63 MB
Available Physical Memory 854.36 MB
Total Virtual Memory 3.40 GB
Available Virtual Memory 2.76 GB
Page File Space 2.00 GB
Page File C:\pagefile.sys
Jul 1, 2005 at 7:55 AM
originally posted by: GretchenSmith

I nuked .NET 1.1.4322 which didn't make any difference at all.

It also throws the exception outside the IDE.

I am going to try the x86 path right now.
Jul 1, 2005 at 8:06 AM
originally posted by: GretchenSmith

some how I have a feeling this has something to do with resources. Running outside the IDE, this is the deepest level of error produced

      • Assembly Binder Log Entry (6/30/2005 @ 1:56:21 PM) ***

The operation failed.
Bind result: hr = 0x80070002. The system cannot find the file specified.

Assembly manager loaded from: C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50215\mscorwks.dll
Running under executable C:\Documents and Settings\gretchen.smith\My Documents\Visual Studio 2005\Projects\CompositeUIBlock\CAB\QuickStarts\BankTeller\BankTellerShell\bin\Debug\BankTellerShell.exe
--- A detailed error log follows.

=== Pre-bind state information ===
LOG: User = IMPACT\gretchen.smith
LOG: DisplayName = Microsoft.Practices.ComponentModel.resources, Version=1.0.40730.0, Culture=en-US, PublicKeyToken=null
(Fully-specified)
LOG: Appbase = file:///C:/Documents and Settings/gretchen.smith/My Documents/Visual Studio 2005/Projects/CompositeUIBlock/CAB/QuickStarts/BankTeller/BankTellerShell/bin/Debug/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = BankTellerShell.exe
Calling assembly : Microsoft.Practices.ComponentModel, Version=1.0.40730.0, Culture=neutral, PublicKeyToken=null.
===
LOG: Start binding of native image Microsoft.Practices.ComponentModel.resources, Version=1.0.40730.0, Culture=en-US, PublicKeyToken=null.
WRN: No matching native image found.
Jul 1, 2005 at 8:35 AM
originally posted by: GretchenSmith

It will run in x86 IF I add the BankTellerSharedModule as a project reference under the BankTellerShell references. Otherwise complained about missing a DLL.

Not able to build x64 but I don't know enough about it to know if it should work -- "System.Data.DLL and mscorlib.dll target a different processor".
Jul 1, 2005 at 8:49 AM
originally posted by: BradWilsonMSFT

Aha! I thought we'd shipped with an explicit project dependency from shell => module, but apparently that slipped through the cracks. Sorry about that. :( Setting the project dependency is definitely the proper way to correct that problem.

This is definitely fixed in the next drop of the code. Thanks a bunch!

So, does this solve your issue of running in x64 mode, or was this just a secondary issue?
Jul 1, 2005 at 8:58 AM
originally posted by: GretchenSmith

Just secondary. Unfortunately it did nothing for the Any CPU (a brief moment of hope, but it didn't last). And targeting x64 directly as I mentioned in above posts has other issues.

At least I can compile and run in x86. I hope I have provided enough information for you to follow up on the Any CPU problems.

Thanks.