[Mono-bugs] [Bug 436189] New: Failed to create shadow copy (CopyFile) exception

bugzilla_noreply at novell.com bugzilla_noreply at novell.com
Thu Oct 16 12:09:59 EDT 2008


https://bugzilla.novell.com/show_bug.cgi?id=436189


           Summary: Failed to create shadow copy (CopyFile) exception
           Product: Mono: Runtime
           Version: 2.0
          Platform: i686
        OS/Version: Windows XP
            Status: NEW
          Severity: Critical
          Priority: P5 - None
         Component: misc
        AssignedTo: mono-bugs at lists.ximian.com
        ReportedBy: francis at aspl.es
         QAContact: mono-bugs at lists.ximian.com
                CC: francis at aspl.es
          Found By: Community User


Created an attachment (id=246039)
 --> (https://bugzilla.novell.com/attachment.cgi?id=246039)
Changes applied to mono/metadata/appdomain.c

Hi,

We are working on a project that loads a set of assemblies from
different directories starting from a base directory. It is fully
functional on Linux (not tested yet on Mac) but on Windows we receive a
"Failed to create shadow copy (CopyFile)" exception just after starting
the app.

Let me describe a bit the application startup. It is a single executable
that loads assemblies found on directories starting from the base path:

c:\application\app.exe
c:\application\Common\skelwindow\skelwindow.dll
c:\application\Common\plugins\plugins.dll
..(and so on)

That is, once app.exe starts, he looks inside Common directory to load
assemblies matching the pattern NAME\NAME.dll

Tracking the problem down to mono/metadata/appdomain.c file, it seems
the function that is failing is get_shadow_assembly_location.

This is because the following call:

        dyn_base = mono_string_to_utf8 (domain->setup->dynamic_base);

.which returns NULL because domain->setup->dynamic_base is also NULL.
This causes the following g_build_filename to also return NULL, making
the caller to fail on CopyFile function (because he tries to copy our
assembly to a NULL location).

We've tried to check which value should have domain->setup->dynamic_base
and why it is NULL, but this goes beyond our knowledge about mono
internals...

At this point we're not sure if this "shadow copy" should happen (since
we don't reload or update those dll on-the-fly). 

PD: All tests are done with mono 2.0 sources, under windows XP
professional with all updates included. I'm also attaching differences
applied to appdomain.c and output produced by them to track the issue.


-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


More information about the mono-bugs mailing list