locked
xmlserializer problem

    Question

  • I have an app which runs fine as myself, but throws an exception (sometime) aftter I install it as a service running as local.system. The exception is UnauthorizedAccesException (see stack trace below).

    1. System has full access to the C:\windows\temp directory
    2. The app manages to write 2 files to this directory (xxxxx.0.cs and xxxxx.tmp). But the rest of the expected temp files are missing (I can see this by setting the below in app.config)
    <system.diagnostics><switches><add name="XmlSerialization.Compilation" value="42/></switches></system.diagnostics>
    3. xxxxx.0.cs is exactly the same as the .cs file written when I run as myself.
    4. The last version of this app exhibited the same exception then suddenly started working for no apparent reason. The only changes I have made in the current version are completely unrelated. (changed some db code)

    thanks for any suggestions

    Alasdair

    Stack trace:

    ERROR Jabre.SophisAdapter.ReconListener - Exception :
    System.UnauthorizedAccessException: Access to the temp directory is denied.  Identity 'NT AUTHORITY\SYSTEM' under which XmlSerializer is running does not have sufficient permission to access the temp directory.  CodeDom will use the user account the process is using to do the compilation, so if the user doesnt have access to system temp directory, you will not be able to compile.  Use Path.GetTempPath() API to find out the temp directory location.
       at System.Xml.Serialization.Compiler.Compile(Assembly parent, String ns, XmlSerializerCompilerParameters xmlParameters, Evidence evidence)
       at System.Xml.Serialization.TempAssembly.GenerateAssembly(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, Evidence evidence, XmlSerializerCompilerParameters parameters, Assembly assembly, Hashtable assemblies)
       at System.Xml.Serialization.TempAssembly..ctor(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, String location, Evidence evidence)
       at System.Xml.Serialization.XmlSerializer.GenerateTempAssembly(XmlMapping xmlMapping, Type type, String defaultNamespace)
       at System.Xml.Serialization.XmlSerializer..ctor(Type type, String defaultNamespace)
       at System.Xml.Serialization.XmlSerializer..ctor(Type type)
       at System.Messaging.XmlMessageFormatter.Write(Message message, Object obj)
       at System.Messaging.Message.AdjustToSend()
       at System.Messaging.MessageQueue.SendInternal(Object obj, MessageQueueTransaction internalTransaction, MessageQueueTransactionType transactionType)
       at System.Messaging.MessageQueue.Send(Object obj, MessageQueueTransaction transaction)
       at Spring.Messaging.Core.MessageQueueTemplate.DoSendMessageTransaction(MessageQueue mq, MessageQueueTransaction transactionToUse, Message msg) in l:\projects\spring-net\trunk\src\Spring\Spring.Messaging\Messaging\Core\MessageQueueTemplate.cs:line 598
       at Spring.Messaging.Core.MessageQueueTemplate.DoSendMessageQueue(MessageQueue mq, Message msg) in l:\projects\spring-net\trunk\src\Spring\Spring.Messaging\Messaging\Core\MessageQueueTemplate.cs:line 575
       at Spring.Messaging.Core.MessageQueueTemplate.DoSend(MessageQueue messageQueue, Message message) in l:\projects\spring-net\trunk\src\Spring\Spring.Messaging\Messaging\Core\MessageQueueTemplate.cs:line 505
       at Spring.Messaging.Core.MessageQueueTemplate.Send(MessageQueue messageQueue, Message message) in l:\projects\spring-net\trunk\src\Spring\Spring.Messaging\Messaging\Core\MessageQueueTemplate.cs:line 487
       at Spring.Messaging.Core.MessageQueueTemplate.ConvertAndSend(String messageQueueObjectName, Object obj) in l:\projects\spring-net\trunk\src\Spring\Spring.Messaging\Messaging\Core\MessageQueueTemplate.cs:line 375
       at Spring.Messaging.Core.MessageQueueTemplate.ConvertAndSend(Object obj) in l:\projects\spring-net\trunk\src\Spring\Spring.Messaging\Messaging\Core\MessageQueueTemplate.cs:line 344
       at Jabre.Messaging.MqManager.Send(Object message, String[] objectNames) in D:\dev\csharp\Server\Server\Messaging\MqManager.cs:line 123
       at Jabre.SophisAdapter.ReconListener.Publish[DataType,MessageType](Object id, String cls, String type) in D:\dev\csharp\SophisAdapter\SophisAdapter\ReconListener.cs:line 134
       at Jabre.SophisAdapter.ReconListener.Publish(CacheKey key, String type) in D:\dev\csharp\SophisAdapter\SophisAdapter\ReconListener.cs:line 103
       at Jabre.SophisAdapter.ReconListener.Start() in D:\dev\csharp\SophisAdapter\SophisAdapter\ReconListener.cs:line 76
    Thursday, January 7, 2010 2:51 PM

Answers

  • Alasdair, I think you're right. Temp files are still generated on the disk, but I believe the assembly itself should be generated in memory. So it looks like #2 won't work for you. But #1 and #3 above should still be valid workarounds. Can you try those out?

    Wednesday, January 13, 2010 7:28 PM
    Moderator

All replies

  • Hi,

    The exception name is very clear

    System.UnauthorizedAccessException

    Why don't you try the same but writing on the 'C:\Users\Username\SomeFolder' path?

    Regards.
    -

    Esteban Murchio.

    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Blog
    Thursday, January 7, 2010 6:09 PM
  • Hey Alasdair,

    It seems like XmlSerializer is having issues with generating a temporary serialization assembly. I have a few suggestions for you:

    1) Choose a different folder to generate serialization assemblies like this:

    <?xml version="1.0" encoding="utf-8" ?>
    <configuration>
      <system.diagnostics>
        <switches>
          <add name="XmlSerialization.Compilation" value="1" />
        </switches>
      </system.diagnostics>
      <system.xml.serialization>
        <xmlSerializer tempFilesLocation="c:\\foo"/>
      </system.xml.serialization>
    </configuration>
    and make sure the system has write privileges for the temp folder you specify.

    2) By default, XmlSerializer temp assemblies are generated in memory and shouldn't be saved to disk. Only when you add the XmlSerialization.Compilation diagnostics switch will you get them saved to disk. So if you remove that switch from your config file, you should stop seeing that error.

    3) Use sgen to generate a serialization assembly beforehand. This will prevent a temp assembly from being regenerated.

    Hope that helps
    Thursday, January 7, 2010 7:33 PM
    Moderator
  • Youssef,
    thanks for the reply.
    re 2) - I was getting the error without the diagnostics switch, I only added that to try and see what was going on. Is there something else which might be causing the serializer to use the disk? What was strange was some files WERE being written out to the disk (the .0.cs file and the .tmp file) and it was only after that that the system was complaining about access to the temp folder.

    I had some other problems on my machine yesterday and had to reboot, after which the process started ok. Trouble is it still doesn't start (same symptoms) on the production machine which I cant just go round rebooting at will .. I was going to try writing to another directory but as it is now working again i'm not sure how to proceed.

    Alasdair

    Friday, January 8, 2010 10:10 AM
  • I confirmed with procmon that XmlSerializer IS writing files to the temp directory when the diagnostics switch is removed - it just deleted them after. As procmon is cauing me to lose network shares i daren't run it on the prod machine (since I no longer get the problem on my machine ...)
    Friday, January 8, 2010 1:08 PM
  • Alasdair, I think you're right. Temp files are still generated on the disk, but I believe the assembly itself should be generated in memory. So it looks like #2 won't work for you. But #1 and #3 above should still be valid workarounds. Can you try those out?

    Wednesday, January 13, 2010 7:28 PM
    Moderator
  • Sorry about the delay in the reply. I used option 1 (relocate temp files) and it works fine. I still don't know why the (random) objection to c:\windows\temp as it has exactly the same permissions as c:\temp.
    Monday, January 25, 2010 7:42 PM