[.Net/Server 2008] Could not load type foutmelding

[P_de_B]

Op een Windows Server 2008 omgeving krijgen we de foutmelding "Could not load type 'System.ArgumentException' from assembly 'mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'" bij een .Net applicatie. Op XP, Vista en Windows Server 2000/2003 krijgen we deze fout niet. Nu weet ik dat mscorlib een bijzonder bestand is omdat vziw altijd de versie in de GAC geslecteerd wordt van deze assembly. mscorlib staat gewoon met de juiste versie in de GAC.

Googlen op deze foutmelding levert eigenlijk als enige oplossing het opnieuw installeren van het .Net 2.0 framework op. Op Server 2008 is dit echter niet (eenvoudig) mogelijk omdat het .Net Framework een OS-component is. Wel een repair uitgevoerd maar die kan geen problemen ontdekken.

Heeft iemand een idee?

[Woy]

Je zou eens op File Nivo kunnen kijken of de assembly hetzelfde is als je andere. Kijk bijvoorbeeld ook eens met reflector of je het type wel kunt laden.

Op File nivo is het een beetje lastig kijken, aangezien je er niet met de explorer kunt kijken, echter kun je er via een command prompt wel gewoon naar toe gaan, en de file kopieren. Ik weet alleen niet of het op die manier ook mogelijk is om die file te vervangen.

Op zich is het natuurlijk wel wonderlijk dat je die assembly niet meer goed kunt laden. Is er misschien een disk corrupt, of misschien iets van een virus?

[P_de_B]

De fout treedt op drie verschillende WIndows 2008 servers op. Het lijkt me niet een fout in de disk oid te zijn. De bestandsversie klopt wel met andere systemen. Het moet volgens mij iets zijn met de manier waarop mscorlib geladen wordt oid. Maar ik heb geen idee verder hoe en wat.

[Woy]

P_de_B schreef op dinsdag 22 december 2009 @ 11:46:
De fout treedt op drie verschillende WIndows 2008 servers op. Het lijkt me niet een fout in de disk oid te zijn. De bestandsversie klopt wel met andere systemen. Het moet volgens mij iets zijn met de manier waarop mscorlib geladen wordt oid. Maar ik heb geen idee verder hoe en wat.

Dan is het wel erg vreemd. Is het 32 of 64 bits Windows. Kun je de assemblies wel laden met bijvoorbeeld reflector?

Krijg je die foutmelding ook als je een simpel test programma maakt die enkel een ArgumentException gooit?

[ Voor 9% gewijzigd door Woy op 22-12-2009 11:52 ]

[Xiphalon]

Gaat er ergens iets mis met Service Pack 1 voor .Net 2.0 (nodig voor 3.0+ versies)?

[P_de_B]

Woy schreef op dinsdag 22 december 2009 @ 11:50:
[...]

Dan is het wel erg vreemd. Is het 32 of 64 bits Windows. Kun je de assemblies wel laden met bijvoorbeeld reflector?

32-bits. Het gebeurt op de omgeving van een klant. Ik heb op dit moment op kantoor geen 2008 omgeving ter beschikking waarop ik kan testen

darkmage schreef op dinsdag 22 december 2009 @ 11:52:
Gaat er ergens iets mis met Service Pack 1 voor .Net 2.0 (nodig voor 3.0+ versies)?

Zoiets verwacht ik eigenlijk, maar de server is helemaal up-to-date volgens windows update. Ik ga ervan uit dat de relevante .Net servicepacks ook geïnstalleerd zijn?

Als het niet anders is moet ik zien dat ik een 2008-omgeving ga inrichten om het hier te testen.

[Woy]

Maar krijg je de fout ook met een simpel test programma? Of word het Type op een speciale manier geladen?

[P_de_B]

Woy schreef op dinsdag 22 december 2009 @ 12:17:
Maar krijg je de fout ook met een simpel test programma? Of word het Type op een speciale manier geladen?

Dat kan ik zo niet 1,2,3 testen omdat ik hier geen omgeving heb voor 2008. Dan moet ik kijken of ik iemand van ICT van de klant kan bereiken of hier een 2008 machine ga inrichten. Wordt in dat geval vervolgd.

[Woy]

Ik zou in dat geval in ieder geval gewoon een VM met Server 2008 maken, dan kun je later ook makkelijker dingen testen. Het is natuurlijk ondoenlijk om problemen op te lossen als je geen goede test-omgeving hebt, en met een VM is het gewoon het makkelijkst om snel iets te testen, zonder dat je telkens opnieuw moet installeren.

[P_de_B]

Woy schreef op dinsdag 22 december 2009 @ 12:25:
Ik zou in dat geval in ieder geval gewoon een VM met Server 2008 maken, dan kun je later ook makkelijker dingen testen. Het is natuurlijk ondoenlijk om problemen op te lossen als je geen goede test-omgeving hebt, en met een VM is het gewoon het makkelijkst om snel iets te testen, zonder dat je telkens opnieuw moet installeren.

Dat snap ik

In principe ondersteunen we op dit moment Server 2008 ook niet, vandaar dat we geen testomgeving paraat hebben. De klant heeft echter toch 2008 en we proberen nu een oplossing te vinden (en een andere dan: herinstalleer je hele Citrix-omgeving maar speciaal voor onze app)

edit: als iemand hier een Windows 2008 omgeving heeft die even wil testen: ik heb inmiddels een hele simple app die deze exception gooit.

[ Voor 8% gewijzigd door P_de_B op 22-12-2009 12:37 ]

[Woy]

Als je hem even mailt, wil ik het wel uit testen.

[P_de_B]

mail is onderweg, bedankt!

[Xiphalon]

Longshot maar treedt hier nogal eens op omdat ze niet kunnen imagen (sysprep vinden 'ze' niet nodig): doet DCOM het? En de Distributed Transaction Coordinator?
Hier moeten we met de hand de logs van de DTC (mstdc -resetlog uitvoeren) resetten, anders krijg je dit soort meldingen.

edit: Staat er iets in het event log?

[ Voor 6% gewijzigd door Xiphalon op 22-12-2009 14:39 ]

[P_de_B]

Er staan geen nadere fouten in het Eventlog. Waarom zou DCOM en DTC van invloed zijn? Ik heb geen idee of dat uit of aan staat.

Het zou uiteraard met de manier van imagen te maken kunnen hebben omdat drie verschillende machines van de klant het probleem hebben.

[Xiphalon]

DCOM, COM+, DTC en het .Net Framework hangen heel dicht aan elkaar (daarom is het ook verrekte makkelijk om COM+ componenten te gebruiken vanuit .Net en andersom).
Maar de foutafhandeling en foutmeldingen van DCOM, COM+ en DTC zijn of afwezig of zo vaag dat je er niets mee kan, maar als er iets is staat 't vaak in het eventlog.

Andere optie: kijk even met dependency walker in de mscorlib.dll om te kijken welke dll's deze nodig heeft en of deze staan op de 2008 bak. Zal vast wel, maar misschien mist er 1.

edit: nog een optie: hebben jullie gerommeld met de standaard (build en project) templates van Visual Studio, en welke versie gebruiken jullie?

Als je namelijk een referentie naar mscorlib maakt dmv een hard pad, gaat het laden goed, maar kan je er geen types uit halen. [edit2:] Kan dit gebeuren door een deserialize actie ofzo?

[ Voor 23% gewijzigd door Xiphalon op 22-12-2009 15:05 ]

[Sybr_E-N]

Wat je eventueel ook nog kan proberen is het tooltje Fuslogvw.exe (Assembly Binding Log Viewer) uit de windows SKD op de achtergrond aanzetten.

Deze tool registreert alle assembly bindings. Je kan dan precies volgen waar vandaar dll geladen worden (lokaal, gac, .net framework dir).

By the way, niet vergeten om het loggen ook weer te ongedaan te maken. Anders blijft dit tooltje voor eeuwig op de achtergrond alle .net assembly binding loggen

[raptorix]

Kan het een verschil zijn dat de file 32 bits is?
Ik had een keer een probleem dat ik dus de 64 bits bestanden had overschreven door 32 bits, koste me 3 uur

[P_de_B]

Ik heb inmiddels intern kunnen testen op een Windows 2008 machine en daar gaat het dus niet fout. Geen idee of ik daar nu blij mee moet zijn of niet trouwens.

Ik kan pas volgende week testen bij de klant helaas.

[P_de_B]

*Kick*

Topic nog maar even omhoog schoppen. We komen op dit moment niet echt verder. We hebben met de Assembly Binding Log Viewer gekeken, maar die geeft geen foutmeldingen. Alle assemblies worden geladen:
Onderstaand het log van mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089:

code:

*** Assembly Binder Log Entry  (28-12-2009 @ 12:12:52) ***

The operation was successful.
Bind result: hr = 0x0. The operation completed successfully.

Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable  C:\Beheer\Software\VCDcrediteuren\WinApp\VCD Crediteuren.exe
--- A detailed error log follows. 

LOG: Found assembly by looking in the GAC.

We krijgen nog wel een waarschuwing op mscorlib.resources:

code:

*** Assembly Binder Log Entry  (28-12-2009 @ 12:13:06) ***

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

Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable  C:\Beheer******************.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: User = *****************\administrator
LOG: DisplayName = mscorlib.resources, Version=2.0.0.0, Culture=nl, PublicKeyToken=b77a5c561934e089
 (Fully-specified)
LOG: Appbase = file:///C:/Beheer/**************/WinApp/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = NULL
Calling assembly : (Unknown).
===
LOG: Start binding of native image mscorlib.resources, Version=2.0.0.0, Culture=nl, PublicKeyToken=b77a5c561934e089.
WRN: No matching native image found.

maar dat lijkt niet relevant, omdat de foutmelding ook aangeeft dat de culture=neutral van mscorlib.


Met een debugviewer hebben we nog wat meer informatie gekregen:

code:

[11048] 06.01.10 13:33:50.277  CurrentObject: nl.vcd.vcllibrary.CreditorSearch(1) 
[11048] 06.01.10 13:33:50.277 Action 'c305b932-e3e7-4da0-ac62-776c79b3bbc0' done 
[11048] 06.01.10 13:33:50.340 ================================================================================ 
[11048] The error occured: 
[11048]  
[11048]  Type:       TypeLoadException 
[11048]  Message:    Could not load type 'System.ArgumentExc?pt?on' from assembly 'mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. 
[11048]  Data:       0 entries 
[11048]  Stack trace: 
[11048]  
[11048]    at DevExpress.XtraGrid.GridGroupSummaryItemCollection.OnInsert(Int32 index, Object item) 
[11048]    at System.Collections.CollectionBase.System.Collections.IList.Add(Object value) 
[11048]    at DevExpress.XtraGrid.GridSummaryItemCollection.Add(GridSummaryItem item)

Wat opvalt is de twee vraagtekens in het woord ArgumentException. Het lijkt me dat deze class (met de vraagtekens) niet bestaat in mscorlib.dll. Blijft natuurlijk de vraag waarom ze er staan, we doen niks bijzonders voor zover bekend. Op vele andere systemen (XP, Vista, Server 2000/2003 en een andere 2008 omgeving) werkt alles gewoon naar behoren. De locale settings van de server staan op Dutch, maar dat staan ze op mijn Vista werkstation ook (en daarop werkt het gewoon).

Wat kan er nu anders zijn op de betreffende systemen?

[raptorix]

Heb je al een repair van je .NET geprobeerd (of eventueel gewoon een reinstall van het framework)?

How to repair an existing installation of the .NET Framework

[Haan]

Laat anders de klant een case loggen bij MS, misschien is het wel een bug in .Net en zit je voor niets al je tijd te verdoen.

[P_de_B]

raptorix schreef op woensdag 06 januari 2010 @ 14:23:
Heb je al een repair van je .NET geprobeerd (of eventueel gewoon een reinstall van het framework)?

How to repair an existing installation of the .NET Framework

We hebben een 'scan now' gedaan, maar die gaf geen foutmeldingen. Herinstallatie is niet mogelijk onder W2K8.

Case bij MS lijkt me niet nuttig, op vele andere omgevingen (ook 2008) werkt het wel gewoon goed.

[Brainstorm]

P_de_B schreef op woensdag 06 januari 2010 @ 14:03:

Wat opvalt is de twee vraagtekens in het woord ArgumentException.

Ik zag in je stacktrace een stuk staan van DevExpress. Het is een longshot, maar: is jullie code of die van third-party componenten (gedeeltelijk) obfuscated?

Ik heb zelf een soortgelijk probleem gehad, waarbij code van een bepaalde leverancier stopte met werken na een update van .NET. Het bleek dat de obfuscator die ze gebruikten niet altijd forward compatible was, na iedere update van het framework moesten we dan ook een nieuwe versie van de software installeren. Ik kan me niet meer herinneren wat de exacte foutmelding was, maar het ging inderdaad ook over types die niet geladen konden worden.

[Verwijderd]

Brainstorm schreef op woensdag 06 januari 2010 @ 14:37:
[...]


Ik zag in je stacktrace een stuk staan van DevExpress. Het is een longshot, maar: is jullie code of die van third-party componenten (gedeeltelijk) obfuscated?

De code van DevExpress lijkt niet obfuscated. Ik heb even met reflector de betreffende DLL opgezocht en gedecopiled, en ik zag netjes de volgende code:

C#:

protected override void OnInsert(int index, object item)
{
    GridGroupSummaryItem item2 = item as GridGroupSummaryItem;
    if ((item2 == null) || base.List.Contains(item2))
    {
        throw new ArgumentException("item");
    }
    base.OnInsert(index, item);
}

Of jullie moeten een andere DLL gebruiken? (Heb net v9.3 maar gedownload).

Vind het wel vreemd dat hij uberhaupt die vraagtekens er neer zet.

[ Voor 20% gewijzigd door Verwijderd op 06-01-2010 15:06 ]

[P_de_B]

We gebruiken een iets oudere versie (9.1), maar die is niet obfuscated idd. We hebben het in ieder geval ook nog bij DX gepost.

[GrimaceODespair]

Ik neem aan dat de vraagtekens consequent op dezelfde plekken verschijnen?

Ook weer een longshot: iets met cultureverschil tss framework en assemblies?

[ Voor 35% gewijzigd door GrimaceODespair op 07-01-2010 13:33 ]

[P_de_B]

GrimaceODespair schreef op donderdag 07 januari 2010 @ 13:30:
Ik neem aan dat de vraagtekens consequent op dezelfde plekken verschijnen?

Ook weer een longshot: iets met cultureverschil tss framework en assemblies?

Jep, de vraaagtekens staan steeds op dezelfde plek. De culture van mscorlib is 'neutral', dat zegt de foutmelding en dat zegt de Assembly Log Viewer (dat culture 'neutral' geladen wordt). Sowieso zou ik niet zo goed weten hoe we dit zouden moeten controleren. We hebben de culture van de server ook nog aangepast, maar dat hielp helaas ook niet.

Overigens treedt het probleem ook op bij een demo applicatie van DevExpress. We hebben het probleem nu maar bij hun aangekaart. Het blijft een lastig iets. Op tig andere omgevingen draait het gewoon goed, waaarom nu niet bij die specifieke klant

[GrimaceODespair]

P_de_B schreef op donderdag 07 januari 2010 @ 20:41:
[...]

Jep, de vraaagtekens staan steeds op dezelfde plek. De culture van mscorlib is 'neutral', dat zegt de foutmelding en dat zegt de Assembly Log Viewer (dat culture 'neutral' geladen wordt). Sowieso zou ik niet zo goed weten hoe we dit zouden moeten controleren. We hebben de culture van de server ook nog aangepast, maar dat hielp helaas ook niet.

Overigens treedt het probleem ook op bij een demo applicatie van DevExpress. We hebben het probleem nu maar bij hun aangekaart. Het blijft een lastig iets. Op tig andere omgevingen draait het gewoon goed, waaarom nu niet bij die specifieke klant

Zijn het alleen W2K8-servers bij die klant die het niet doen? En is dat dan in een domein?

[eek]

Staat 3.5 ook op die server? Kan je die wel opnieuw installeren? Misschien heeft die installatie het bestand corrupt gemaakt