SOA*.tmp Files on Local C: drive


  • I'm not sure if this is the correct forum, but we have a number of PCs and mapped network drives filling up with 0KB files written to the root of the drive.  The filenames are SOA*.tmp

    Here's an example of files written to my hard drive on 9/16 and 

    There were a total of 1057 files up until today - Monday 12/16

    C:\>dir SOA*.tmp /O:D
     Volume in drive C is Windows
     Volume Serial Number is 5225-7630

     Directory of C:\

    09/16/2013  10:41 AM                 0 SOA4E6.tmp
    09/16/2013  10:41 AM                 0 SOA1388.tmp
    09/16/2013  10:41 AM                 0 SOA13C7.tmp
    09/16/2013  02:51 PM                 0 SOA23ED.tmp
    09/16/2013  02:51 PM                 0 SOA28DE.tmp
    09/16/2013  02:52 PM                 0 SOA29D9.tmp
    09/17/2013  08:05 AM                 0 SOA46A3.tmp
    09/17/2013  08:05 AM                 0 SOA7B8A.tmp
    09/17/2013  08:05 AM                 0 SOA7BE8.tmp
    09/17/2013  08:08 AM                 0 SOAEF74.tmp
    09/17/2013  08:08 AM                 0 SOAF61B.tmp
    09/17/2013  08:08 AM                 0 SOAF64B.tmp
    09/17/2013  09:32 AM                 0 SOA5AAC.tmp
    09/17/2013  09:32 AM                 0 SOA5B0B.tmp
    09/17/2013  02:25 PM                 0 SOAFEE2.tmp
    09/17/2013  02:25 PM                 0 SOAFF60.tmp
    09/17/2013  02:30 PM                 0 SOAEE13.tmp
    09/17/2013  02:30 PM                 0 SOAEE72.tmp
    09/17/2013  02:35 PM                 0 SOA227E.tmp
    09/17/2013  02:35 PM                 0 SOA2F7B.tmp
    09/17/2013  02:35 PM                 0 SOA2F9B.tmp

    We are not sure where they are coming from, but we would like help in identifying troubleshooting steps or what application they are related. 

    Monday, December 16, 2013 7:26 PM


All replies

  • Monday, December 16, 2013 8:41 PM
  • Did you ever find out what was causing these SOA*.tmp files?  I have the same issue and I'm not having any luck with auditing.  Any help would be greatly appreciated, thank you in advance!


    Wednesday, January 29, 2014 11:52 PM
  • I had a same case: in the folder C:\DFSRoots\dfs were created SOA*.tmp files. Analysis of events in the system logs did not give any information on the origin files.

    I would be grateful if there is new information on this issue.

    Wednesday, March 05, 2014 10:55 AM
  • Question for you Sergey: Are you running Symantec 12.1?


    Thursday, March 27, 2014 5:44 PM
  • Yes, we use SEP 12.1 on our server.
    Friday, April 11, 2014 2:17 PM
  • Interesting. I believe this issue is tied to SEP. Perhaps an upgrade didn't go as planned. In my case, the files are left in a "Public" drive space by one of my users. I'm going to un-install/re-install SEP on that computer.


    Friday, April 11, 2014 2:28 PM
  • Hi, if the auditing does not work, I would do a small capture with processmonitor

    A filter like that should work. I put in it c:\temp, because I created a file there to test the filter, and yes it worked, for you I suggest c:\SOA. The second image show that it only displayed event with that in the path, in that case I manually created the file.

    Regards, Philippe

    Don't forget to mark as answer or vote as helpful to help identify good information. ( linkedin endorsement never hurt too :o) )

    Answer an interesting question ? Create a wiki article about it!

    Saturday, April 12, 2014 1:50 AM
  • Some Windows 7 (64-bit) workstations at work were writing SOA*.tmp files (0k bytes) to their hard disks' root directory.


    I was able to determine that Outlook 2010 (32-bit) was involved. When an image is pasted in the body (a.k.a. "inline", not an attachment) of an Outlook 2010 email, the  SOA*.tmp file was written to the root of the hard disk as soon as the "Send" button was  clicked. I confirmed this on multiple workstations.


    There was one colleague of mine, however, who checked her workstation after emailing an image, but she did not find any SOA*.tmp files. Later on, she noticed that she was sending email from Outlook 2010 as "HTML" by default, whereas persons with the SOA*.tmp files on their root were sending their emails as "Rich Text" by default. We were able to confirm on every workstation that we tested that the user could toggle between writing the SOA*.tmp and not writing the file by switching the default email type between "Rich Text" and "HTML".


    We were not able to determine how to change the location where the SOA*.tmp files were being written.



    • Proposed as answer by NrajivK Monday, December 01, 2014 12:03 PM
    Thursday, May 22, 2014 3:09 AM
  • Very helpful information StrutTowerBrace.
    I've noticed heaps of this files on our files serves where users' documents are directed to, SOAxxx.tmp fies are in d:\MyDocs, users documents are directed to d:\MyDocs\%username%. But also seen some on network drives with no link to redirected folders.

    I tested with Outlook 2016 on Windows 8.1, new email, changed format to rich text, inserted picture, sent email and SOAEFE1.tmp was created on the file server with my username as the owner.

    Any idea how to fix this now?

    Friday, May 27, 2016 1:27 AM
  • Steven, did uninstalling and reinstalling SEP worked for you?  I'm having this problem too with one of our users.

    Thursday, June 08, 2017 6:09 PM
  • I don't think it's SEP. I logged a ticket with Microsoft, confirmed it was Outlook doing it, but they wouldn't say it's a bug in Outlook and couldn't say why it was actually creating the file. Their "fix" was to change permissions on the root of the share to users don't have rights to create files there. 1 of our file servers is already setup like that, and doesn't have any of the SOAxxx.tmp files on it.
    Friday, June 09, 2017 8:03 PM
  • Has anyone being able to get to resolve this?

    We're seeing these files appear more frequently, on the local C:\ and the users Home directory on the file server.

    Currently masking the issue by running a script to delete the files on a daily basis, but would like to try and get to the bottom of it.

    Wednesday, January 03, 2018 4:28 PM