Thanks for your answer michael,
as i said, in fact, the debug version is ok everywhere
the release version fails everywhere

it's not a problem of windows explorer ...

the event log tells me :

Faulting application workbench.exe, version 0.0.0.0, stamp 4458379d,
faulting module kernel32.dll, version 5.1.2600.2945, stamp 44ab9ae6,
debug? 0, fault address 0x00012a5b.

You have a bug that is obscured somehow in the debug version.

In C#, the most common way for this to happen is to explicitly contain  
some code with "#if DEBUG", since the usual "uninitialized variable" stuff  
doesn't come up (heap-allocated stuff is always initialized to default  
values and local variables are required by the compiler to be initialized  
before use).  However, you might have some debug-related code (for  
example, using the Debug.Assert() method where the clause in the method  
has a side-effect).  This is not an exclusive list, but is the most common  
ways I can think of that might cause this sort of thing.

Finding the exact problem might be tricky, but frankly since you have a  
reproducible crash in the release version, why not just run the release  
version under the debugger and take a look at the crash?  See what's wrong  
and think about what code should be making it right and why that code  
might not be executing, or might be doing the wrong thing, under the  
release version of the build.

Pete