We're sorry Aspose doesn't work properply without JavaScript enabled.

Free Support Forum - aspose.com

Regarding the memory issue


I used the Aspose dll to create pst file.It works fine for small files.
But there are some eml samples for that it took high memory.Even after it doesn’t release memory.
That is ok it took memory while loading the eml file but afterwords it should release it.
Even I observe that when I load multiple eml file one after other the memory got piled up.

Please consider this issue on priority basis.I am using Aspose.Email.dll (
I have attached one sample msg file for which also it took large memory and doesn’t release it.

Kindly waiting for your reply.

Thanks and Regards,

Hi Shital,

Thank you for contacting Aspose support team.

I have tested the scenario using Aspose.Email for .NET 4.2.0 and added the sample message multiple times in a PST. It is observed that memory usage increases while message is being added into PST repetitively, however once the process is completed, memory is back to its initial state as it was before starting the program.

Could you please test the scenario again using above mentioned latest DLL and let us know your feedback?

Following sample code is used for testing:

MapiMessage mapi = MapiMessage.FromFile(@“D:\Aspose\sample\Sample.msg”);
PersonalStorage pst = PersonalStorage.Create(@“D:\Aspose\sample\pstFile.pst”, FileFormatVersion.Unicode);
FolderInfo outfolder = pst.RootFolder.GetSubFolder(“TestFolder”);
for (int i = 0; i < 10; i++ )


I am using Aspose.Email.dll(4.2.0). Since I am dealing with the lakhs of mails to add to pst file.
The whole procedure of adding message to pst ends with the memory licks.
When I am adding messages one after another the memory get piled up and eventually application got crash.

Will you check with the large number of messages.

Thanks and Regards,

Hi Shital,

I have tested the scenario by adding about 70000 messages in a PST reaching size upto 10 GB, but afraid to inform that I could re-produce the issue here. You may please try by calling Dispose function for the messages which are added to PST.

You may also try writing the PST in memory such that memory is flushed to disc periodically to release the memory. Could you please give a try to the following sample code and let us know your feedback?

static void TestPSTInMemory3()
string dir = @“D:\Aspose\PSTInMemory”;
File.Delete(dir + @“AnotherSample.pst”);
FileStream fileToSave = new FileStream(dir + @“AnotherSample.pst”, FileMode.Create, FileAccess.Write);
MemoryStream memStr = new MemoryStream();
using (PersonalStorage pst = PersonalStorage.Create(memStr, FileFormatVersion.Unicode))
FolderInfo fInfo = pst.CreatePredefinedFolder(“Inbox”, StandardIpmFolder.Inbox);
MapiMessage mapi = new MapiMessage("from@domain.com", "to@domain.com", “Subject”, “Body”, OutlookMessageFormat.Unicode);
for (int i = 0; i < 3000; i++)
mapi.Subject = mapi.Subject + i;
//Following line will release the memory after each message is written to file.
//You may put some logic to flush it after every 100 or 1000 messages say
Console.WriteLine(i + " Messages written to file");


I will test with the suggested changes.
But with testing I am also came across one more issue.
It throws exception as follows for more than 30 thousand mails when I am testing for large number of mails.
Exception is as follows
at ..( )
at .?.?( , ? , )
at .?.?(UInt16 , UInt32 , )
at .?.?( )
at .?…ctor( , )
at ..(UInt32 )
at .??.??()
at .??.??()
at .??.Load()
at .??.??(MapiPropertyCollection , Boolean )
at ..?(MapiMessage , FolderInfo , ?? , Boolean )
at ..AddMessage(FolderInfo , MapiMessage , ? , ?? , Boolean )
at ..AddMessage(FolderInfo , MapiMessage )
at Aspose.Email.Outlook.Pst.FolderInfo.AddMessage(MapiMessage message)
And it is come in v 4.2 .It is difficult to trace out sample.But if possible I will provide you sample.But it is great if you find the issue by observing exception.

Thanks And Regards

Hi Shital,

As mentioned earlier, I have tried this scenario with 70k mails but no issue was observed. Also the stack trace shared here is not that helpful to resolve the problem. Therefore, for further analysis I would like to request you to share your sample messages with us. It will help us to re-produce the scenario and provide solution as soon as possible.

We are sorry for the inconvenience caused to you in this regard.