I am trying to blow some steam in this post, and also would hope that one of the expert programmers that frequent this board could shed some light on these issues.

here it goes.

I have an application (it is C++ Visual Studio code, not C#)that refuses to load in ollydbg. It throws an invalid floating number exception that is impassable.
The app loads OK from the windows loader, then I can attach it to OLLy after the fact, but does not load it from scratch.

I was trying to zero-in to the code where the exception is generated. I was able to load in the App in OLLY by making the first stop at system breakpoint and then after each .dll is loaded.

That is where my problems started.
apparently the exceptions happens after the module
Path=g:\windows\assembly\gac\accessibility\1.0.5000.0__b03f5f7f11d50a3a\accessibility.dll
Gets loaded

But such folder does not exist.

This GAC is the global assembly cache, which is part of the F@4king .NET framework. While OLLy perceives it as a regular library, this "accessibility.dll" has a virtual existence and cannot be easily located in the system folders.

I found several tools to try to understand what accessibility.dll did that was messing up the correct loading of my program.

accessibility.dll is a very small module, 8kb, so I proceeded to delete it to see where my target program would complain . . .

Disaster: my whole system became unstable. It started freezing. After a reboot, it did not recognize my administrator password an privileges and essentially lock me out of the system.

4 hours later I was able to reinstall/salvage windows installation to a more stable yet still problematic state. dotnetfx refused to reinstall, claiming that it was already installed.

I finally had to dig out the bloody accessibility\1.0.5000.0__b03f5f7f11d50a3a\accessibility.dll by unpacking dotnetfx CAB files and manually reinstall it. Note: you cannot COPY the DLL, because it Edit: Does NOT "exist" like a normal file. You have to use a special tool, in my case "gacview", to replace it.


So what is the fucking GAC in .NET, why is it so mysterious and finicky to handle, and why is it so invasive: deleting a single 8 kb DLL sent all my system to hell. One would think that .NET is new ADD-ON accessory, not a fundamental part of the windows inner working

Howdy,

WHAT THE FUCK IS WRONG WITH YOU ?

You can use the word fuck. Fuck'em if they dont like it
fuckity fuck fuck fuck.

W

Now that your computer is working again... have you tried looking at the Call Stack in OllyDbg when the exception is hit? Perhaps this will allow you to find where the exception is coming from.

O RLY? I think you just don't have permissions to the folder.

http://img143.imageshack.us/img143/1448/gacnk4.png

My hypothesis is that during startup, some program either needs .NET or .NET itself does something like initialise, which explains why the missing DLL had an effect.

.NET can certainly be a bitch to work with. Luckily I only have two, rarely used programs that require it (and if I had lots of spare time, I would've probably reversed those and wrote my own non-.NET versions )

Thanks for the responses:
@Disa:
the Call stack takes me as far as:
G:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\mscorwks.dll

Which is still part of the .NET framework, and should not be a generic antidebug measure.

@ Litana: True. a cmd window can seamlessly navigate into the GAC folder and beyond.
The windows explorer or a file search does not "SEE" beyond g:\windows\assembly, where you will find virtual shorcuts to the .NET framework. GACVIEW allows direct manipulation of the .dlls

I do have full administrator permissions, so I can access the GAC folder, although indirectly, using gacview or gacutils. It is the windows GUI that has obstacles allowing direct view/copy/install of those files. Apparently windows treats the contents of the GAC area like an extended registry, whose "keys" are assembly code modules, which are used and reused by multiple apps.

I understand if you're reluctant to mess with that accessibility.dll file again, but have you tried to patch in a looping jump or INT3 at the first instruction of its DLL-main (if needed), and single-step this function during loading in your app?

PS. Make sure to restore the patch before rebooting.

Damn, I thought George Carlin was dead.

Now where did I leave that box of cheese tits.

No luck there. . .
The file is written in .NET assembly.
It has a PE header. IDA can disassemble it, but I see no conventional X86 asm code inside it. Back to the drawing board

i dont know heads or tails about this dotnet
but have you tried Russel osterlunds (smidgeonsoft's) pebrowse


should be a good place to start is what i have heard

and he has painstakingly created lots of tutorials about his utilities

http://www.smidgeonsoft.prohosting.com/documentation/pebrowse-entry-points-introduction.html

http://www.smidgeonsoft.prohosting.com/documentation/pebrowse-pro-interactive-debugger-tutorial-introduction.html

Administrator not powerful enough? Try using the SYSTEM account

http://img88.imageshack.us/img88/1168/gacbx8.png

Also I've heard that the latest versions of IDA can disassemble .NET bytecode as well...

Interesting. Naides, I could look at your program, as I'm working with .NET for quite some time (even had Vista as primary OS at home when my XP went to hell and I couldn't reinstall it cause of broken floppy with SATA drivers ).

On the subject, one thing that I noticed. Newer versions of Visual Studio (don't remember, 7 or just 8) like to bind executables with .NET even if they are pure unmanaged C++ code. I had a problem when my simple C tool refused to run on a machine without .NET installed. I think it's hidden somewhere in the project/linker settings, but that may be the cause of "mysterious" .NET assemblies being loaded at the start in your case.

Other stuff.. You can dive into "real" GAC with Total Commander or, well, anything but Windows Exploder. And "accessibility.dll" makes me thing about, DOH, accessibility features. Maybe you have some accessibility functions enabled (see in control panel), try to disable them if so. This could be the reason for such dll being loaded to your process (or every process, I suspect).

The GAC can be viewed from Windows Explorer if you go to
HKLM\Software\Microsoft\Fusion\DisableCacheViewer

and change the DWORD to 1.

Global Assembly Cache is where Windows stores the native compiled images of its .NET executables after execution, so it doesn't need to recompile them every time the app is executed.

I actually spent a weekend playing around with the GAC produced executables, trying to convert them to nice, native, working exe's. I managed to retrieve some code, but it still points to .NET API's such as System.Forms.dll, and I have no idea how to get them to work with the exe...
That and the fact that I am a noobie around the PE file format and import tables discouraged me from looking into it any further....

EDIT

Because of this post I started reading about NGEN again a bit, to see if there were any major updates. It appears in .NET 2.0 they added a /Debug switch that allows you to create native executables that are runnable under a debugger. Interesting. I'll take a further look when I get home.

Here's NGEN for all interested:
http://msdn2.microsoft.com/en-us/library/6t9t5wcf(VS.80).aspx

You know that when I mean Fuck, is Fuck.
The problem with that .NET debacle was so annoying, and the .NET platform is so distinctive that calling it a plain old fuck just did not cut it, was not enough.

.NET is so Shitfully innovative, unnecessarily complex F*&ing new product from Microf*&k.

That's all

Well ... At least that clear's THAT up.

Regards,

At least it's faster than Java

Fucking HUH?????
Not the apps I've played with - you could soft boil an egg while they're loading.

SiGiNT

Hmm... I don't know who's been writing the apps you're using, but it sounds like they're doing something wrong. All of the .NET apps that I've written run really quickly.

Java is teh best ever.

Let the flame war begin.

NOTE: If you ever want to read something amusing, look up "Internet troll" on wikipedia. They have a 6 page intellectual discussion on what is, basically, just people being dickheads.

They're both nearly the same. Efficiencies of 1/1000 and 1/1001 aren't much different

...and that's a "positive" estimate of % efficiency... maybe something in the range 1/10000 - 1/100000 would be a bit more realistic.

Ah, the flames.. ;D

.NET assemblies can load slowly for the first time because:
a) whole framework might need to be loaded (only one time per session)
b) the code is compiled to the native equivalent "on the fly", so at the start "main" class and constructors are compiled, and then the rest following with the program flow.

.NET assemblies run about as fast as similar C/C++ code (although exceptions are slow in c#). Don't believe it? Test it yourself and don't begin with "I haven't seen this movie but it's horrible!". There is some overhead ofcourse, but not much. The main drawback of .NET is memory requirements - it's hard to control it as good as with unmanaged code.

Example
Simple arithmetic/logic program: Eratosthene's sieve in both C and C#
http://omeg.ry.pl/progs/sito.zip
http://omeg.ry.pl/progs/sitonet.zip

Could be I have a distorted impression, just tested the one I use most often - about 15 sec.'s to load the first time - about 5 after, but on my laptop, I'm sure it takes a good 30-45 sec. to load the first time, and yes it's poorly written, everything in one huge executable, no msil's. - And no flame wars here, I just have a personal opinion that this language ranks somewhere in between GWBasic and VB.

SiGiNT

Fair enough.

I could write a program in raw x86 ASM that takes 60 seconds to load

Indeed, you can write horribly inefficient code in any language, but what is more relevant is the maximum efficiency that can be attained with it; Asm's maximal efficiency is almost nearly 100%, whereas I'd estimate most HLLs to be somewhere between 1 and 10%.
This is one of the reasons why I rather dislike .NET - if it's going to be compiled anyway, why not just compile it once and distribute the binary, instead of having to compile it every single time it's executed?

Only if you were trying to

Security and portability are two key reasons, and I'm sure there are others.

Plus you don't compile it every single time - the programs which are used most often are cached so the JIT doesn't have to start over.

-niko

Hey Nikola, long time no see, nice to see you around.

With the new C++/CLI in VS 2005, a C++/CLI .NET app can faster than a VB.NET or C# for .NET app.