USysWare Support Forums

by **Chris Nahr** » January 30th, 2009, 5:03 am

Very curious bug with DPack 2.8.8 running in Visual Studio 2008 SP1 on Vista x64...

Everything seems to work fine, except when I try to bring up the Framework Browser. Visual Studio pauses briefly... then simply shuts down! This happens regardless of whether a solution is currently open.

With logging enabled, I see the following output in the FCLBrowser.log file:

09:58:25.655 *** Start logging ***
09:58:25.655 Date: 1.30.09
09:58:25.655 Version: 2.8.8.0
09:58:25.655 Runtime: 2.0.50727.3053 SP2
09:58:25.655 IDE: 9.0.21022
09:58:25.655 OS: Windows Vista Service Pack 1 (6.0.6001.65536)
09:58:25.655 Create Cache - begin
09:58:25.671 Assembly folder: C:\Windows\Microsoft.NET\Framework\v2.0.50727\
09:58:25.671 Assembly folder: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.0\
09:58:25.671 Assembly folder: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\

Then it just stops. The other log files show nothing but the usual initialization messages. Running DebugView alongside VS2008 shows no output, either.

I recall that the Framework Browser did work in earlier versions/installations but unfortunately I don't know when it stopped working.

UAC is disabled on Vista and I'm running as administrator, so there shouldn't be any permission issues. DPack is installed to C:\Development\DPack, and I tried reinstalling 2.8.8 without success.

by **Sergey** » January 30th, 2009, 12:13 pm

Hi Chris,

That's not good. Must be some assembly loading issue, which I'm sure has to do with Vista 64-bit. I'll look into that over the weekend and will let you know.

Thanks for reporting it.

by **Sergey** » January 31st, 2009, 2:28 pm

Hi Chris,

All worked fine here on my 64-bit Vista SP1 VM. So, I'm guessing it's either hitting some assembly it really doesn't like, or perhaps running into some other condition.

What's odd is that the way DPack's designed is so that no unhandled exception should ever be propagated to avoid any possible VS crashes. I'm sure you've tried your share of tools that crash VS. I wanted to avoid that at all cost.

In any case, I've posted a beta for you try, which will log whole a lot more information about the assembly/type caching progress. That should hopefully help me identify the trouble spot. Before starting Framework Browser, make sure that DPack's logging is enabled. It's on Tools|Options dialog, DPack->General page.

Please see changelog in the installation folder for the list of changes in this beta. Also moving forward, you should be able to use DPack's 'Check For Updates' menu item to check for new beta. Previously, it'd only check for new GA release updates.

Let me know how it goes. Thanks.

http://www.usysware.com/files/DPackSetup2008Beta.exe (769Kb)

by **Chris Nahr** » February 1st, 2009, 4:08 am

Okay, I'll install this version and will post the log file when I have it.

by **Chris Nahr** » February 1st, 2009, 4:12 am

Already done.

Same result as before, except that the log file is quite a bit longer. I tried calling up the Framework Browser twice, the resulting log file was the same in each case:

09:11:58.687 *** Start logging ***
09:11:58.687 Date: 2.1.09
09:11:58.687 Version: 2.9.1.3
09:11:58.687 Runtime: 2.0.50727.3053 SP2
09:11:58.687 IDE: 9.0.21022
09:11:58.687 OS: Windows Vista Service Pack 1 (6.0.6001.65536)
09:11:58.690 Create Cache - begin
09:11:58.697 Assembly folder: C:\Windows\Microsoft.NET\Framework\v2.0.50727\
09:11:58.697 Assembly folder: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.0\
09:11:58.697 Assembly folder: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\
09:11:58.697 AppDomain: assembly C:\Development\DPack\DPack.dll
09:11:58.742 AppDomain: created
09:11:58.742 AppDomain: data's setup
09:11:58.742 AppDomain: create and unwrap instance USysWare.Drivers.FCLBrowser.AssemblyLoader
09:11:58.747 AssemblyLoader: created
09:11:58.747 AssemblyLoader: get assembly list
09:11:58.748 AssemblyLoader: cache assemblies
09:11:58.985 AssemblyLoader: process cached assembly names - 91
09:11:58.985 AssemblyLoader: process mscorlib
09:11:58.997 AssemblyLoader: process CustomMarshalers
09:11:58.999 AssemblyLoader: process PresentationCore
09:11:59.022 AssemblyLoader: process System.Data
09:11:59.031 AssemblyLoader: process System.Data.OracleClient
09:11:59.033 AssemblyLoader: process System.EnterpriseServices
09:11:59.039 AssemblyLoader: process System.Printing
09:11:59.067 AssemblyLoader: process System.Transactions
09:11:59.070 AssemblyLoader: process System.Web
09:11:59.089 AssemblyLoader: process Accessibility
09:11:59.090 AssemblyLoader: process cscompmgd
09:11:59.092 AssemblyLoader: process IEExecRemote
09:11:59.093 AssemblyLoader: process IEHost
09:11:59.099 AssemblyLoader: process IIEHost
09:11:59.099 AssemblyLoader: process Microsoft.JScript
09:11:59.105 AssemblyLoader: process Microsoft.VisualBasic
09:11:59.108 AssemblyLoader: process Microsoft.VisualBasic.Compatibility
09:11:59.124 AssemblyLoader: process Microsoft.VisualBasic.Compatibility.Data
09:11:59.137 AssemblyLoader: process Microsoft.VisualBasic.Vsa
09:11:59.139 AssemblyLoader: process Microsoft.VisualC
09:11:59.140 AssemblyLoader: process Microsoft.VisualC.STLCLR
09:11:59.148 AssemblyLoader: process PresentationBuildTasks
09:11:59.166 AssemblyLoader: process PresentationFramework
09:11:59.173 AssemblyLoader: process PresentationFramework.Aero
09:11:59.175 AssemblyLoader: process PresentationFramework.Classic
09:11:59.178 AssemblyLoader: process PresentationFramework.Luna
09:11:59.180 AssemblyLoader: process PresentationFramework.Royale
09:11:59.182 AssemblyLoader: process ReachFramework
09:11:59.185 AssemblyLoader: process sysglobl
09:11:59.186 AssemblyLoader: process System
09:11:59.193 AssemblyLoader: process System.AddIn
09:11:59.197 AssemblyLoader: process System.AddIn.Contract
09:11:59.197 AssemblyLoader: process System.ComponentModel.DataAnnotations

by **Chris Nahr** » February 1st, 2009, 4:22 am

So I went looking for that last file where DPack stopped, and found it in the following folder:

C:\Windows\assembly\GAC_MSIL\System.ComponentModel.DataAnnotations\3.5.0.0__31bf3856ad364e35\System.ComponentModel.DataAnnotations.dll

The size of this file is 57.344 bytes. Windows Explorer tells me its public key token is exactly what you see abover (after the 3.5.0.0), and its file & product versions are 3.5.30729.1. The CRC checksum is 441240814.

That's the only occurrence of this file on my C: drive. Doesn't seem anything wrong with it...

by **Sergey** » February 1st, 2009, 1:45 pm

It should also be in the following folder:

C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5

I suspect there is gotta be something wrong with the way that assembly is registered in GAC. That path you posted is actually assembly's GAC path. The one above is used to reference assemblies in the project.

If you don't mind running a couple more tests, then here's what you can do.

1. Create a new WinForms project with .NET 3.5 selected as a target framework. Then trying referencing System.ComponentModel.DataAnnotations assembly and see if it works.

2. Repair your .NET 3.5 SP1 installation from Control Panel, Program/Features. Try Framework Browser again after that.

3. As a last resort, add System.ComponentModel.DataAnnotations to FCLExclude.dat file located in DPack's installation folder. One line per assembly name. Restart VS and try Framework Browser again.

Let me know how it goes please. Thanks.

by **Chris Nahr** » February 2nd, 2009, 4:02 am

Sergey wrote:It should also be in the following folder:

C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5

Indeed it's there, too! Sorry about the confusion, I forgot that the Total Commander file search is exact, so I found only the GAC directory rather than the actual DLL. Searching with the dll extension finds both files, and also another instance in Program Files\Reference Assemblies (presumably the 64-bit version).

1. Create a new WinForms project with .NET 3.5 selected as a target framework. Then trying referencing System.ComponentModel.DataAnnotations assembly and see if it works.

Works without a hitch. I can add the assembly reference, get Intellisense for the namespace, and can declare a DataType variable (an enum in that namespace).

2. Repair your .NET 3.5 SP1 installation from Control Panel, Program/Features. Try Framework Browser again after that.

Okay, trying that... did not help. Repair completes successfully, the DataAnnotations assembly is unchanged, Framework Browser still shuts down Visual Studio, log file still ends at this assembly.

3. As a last resort, add System.ComponentModel.DataAnnotations to FCLExclude.dat file located in DPack's installation folder. One line per assembly name. Restart VS and try Framework Browser again.

Okay, now I'm trying that... works! Framework Browser comes up correctly now. So it was really just the DataAnnotations assembly, but apparently it's the correct and undamaged assembly! Very weird. The log file still doesn't show any errors, it just runs through all assemblies normally.

Thanks for your help, it's nice to be have the Framework Browser back.

by **Sergey** » February 2nd, 2009, 11:13 am

Since all tests worked fine, I'm afraid I'd have to say it's something about that assembly on your system and how DPack loads it VS doesn't like very much. Wish I could reproduce it here...

In any case, I'm gonna make that .dat file change permanent to avoid similar problems in the future. Thanks for your help!

USysWare Support Forums

Framework Browser shuts down VS2008

Framework Browser shuts down VS2008

Who is online