none
powerpoint memory leak in slideshow RRS feed

  • Question

  • I have a simple piece of code where there will be many updates on a textbox on a slide during the slideshow. I really need to code to work without interruption.

    Problem is that there is a memory increase that is never released. I'm trying to call theReleaseComObject already and saving the presentation regularly (this worked in 2003!).

    Does someone has a solution for this? Thanks.

    So I have this code in VS vb.net, office powerpoint 2010 addon

    Imports System.Runtime.InteropServices

    Public Class ThisAddIn

    Dim WithEvents tmrUpdate As System.Timers.Timer

    Dim WithEvents tmrSave As System.Timers.Timer

    Private Sub ThisAddIn_Startup() Handles Me.Startup

    End Sub

    Private Sub ThisAddIn_Shutdown() Handles Me.Shutdown

    tmrUpdate.Stop()

    tmrUpdate.Dispose()

    tmrSave.Stop()

    tmrSave.Dispose()

    End Sub

    Private Sub Application_SlideShowBegin(Wn As Microsoft.Office.Interop.PowerPoint.SlideShowWindow) Handles Application.SlideShowBegin

    tmrUpdate = New System.Timers.Timer

    With tmrUpdate

    .Interval = 50

    .AutoReset = True

    .Start()

    End With

    tmrSave = New System.Timers.Timer

    With tmrSave

    .Interval = 10000

    .AutoReset = True

    .Start()

    End With

    End Sub

    Private Sub tmrUpdate_Elapsed(sender As Object, e As System.Timers.ElapsedEventArgs) Handles tmrUpdate.Elapsed

    Dim newtext As String = Now.Millisecond

    Dim activeslide As PowerPoint.Slide = Application.ActivePresentation.Slides(Application.ActivePresentation.SlideShowWindow.View.CurrentShowPosition)

    For Each sh As PowerPoint.Shape In activeslide.Shapes

    With sh

    If .HasTextFrame Then

    With .TextFrame.TextRange

    .Text = newtext

    End With

    End If

    End With

    Marshal.ReleaseComObject(sh)

    Next

    Marshal.ReleaseComObject(activeslide)

    GC.Collect()

    GC.WaitForPendingFinalizers()

    GC.Collect()

    End Sub

    Private Sub tmrSave_Elapsed(sender As Object, e As System.Timers.ElapsedEventArgs) Handles tmrSave.Elapsed

    Dim apres As PowerPoint.Presentation = Application.ActivePresentation

    apres.Save()

    Marshal.ReleaseComObject(apres)

    End Sub

    End Class

    Tuesday, November 6, 2012 4:54 PM

Answers

  • Hi Kurt,

     

    I checked with the PowerPoint Engineering team.  PowerPoint's behavior since 2007 has indeed changed to not purge the undo stack when saving the document.  For normal users, this is actually a great feature, because that way you don't have to have a conflict between wanting to save versus wanting to be able to undo.  However, this lack of undo-stack-purging, combined with a change to have multiple consecutive Object-Model calls be merged into a single undo entry, does explain the scenario you were describing.  The combined effect can indeed cause memory usage to continue to increase, if no intervening "user" edit is made to prevent further Object-Model calls from merging, or some other operation which causes the undo stack to be cleared.

     

    There are two workarounds I can suggest:

     

    1. As it so happens -- though this certainly isn't guaranteed to be the case in the future -- saving to a binary PowerPoint file (e.g, .ppt rather than .pptx) will cause the undo stack to be cleared.  I'm not sure if there are any adverse effects for saving as a binary file, though, and you shouldn't rely on this behavior continuing to be the case down the road.  E.g., I would treat it as more of a short-term solution. 
    2. Depending on how often you need to purge the undo stack, and if it's ok for the screen to flash for a second during that time, the more long-term workaround might be to have a timer/trigger that quickly closes the presentation and immediately re-opens it and re-launches the slideshow from wherever the slideshow left off.  The undo stack in PowerPoint is per-document, so if you close the document and re-open it, you should have a blank slate.  Just make sure that the instance of PowerPoint (and hence your Add-In code) doesn't close when you close the document:  that way, you'll be able to immediately re-open with little interruption.  The downside is that some screen flickering -- while the document closes and re-opens -- is probably close to unavoidable.  The question is, how quickly the change can happen, versus how long will the slideshow will be running before you need to do the swap.  If it's for 2 seconds once every few days, that might be good enough for your context.

     

    Hope this helps.  Let me know if you have further questions.

    All the best,

    - Michael


    Michael Zlatkovsky | Program Manager, Visual Studio Tools for Office & Apps for Office

    Wednesday, December 5, 2012 1:44 AM
    Moderator

All replies

  • Hi Kurt,

    I tried running your code, and it seemed to be working fine (modulo the fact that you don't turn off the timer when the user quits the presentation, but that's a different issue).

    What makes you think that memory is increasing -- what tool are you using to measure this, and what adverse impact does it have? (e.g., could it be that memory increases for a little bit, but then garbage-collects, so it's really not a problem?)  For that matter, I'm not actually clear on what would cause you to rack up memory anyway.

    If you reply with more info, I'll be happy to look into this,

    - Michael


    Michael Zlatkovsky | Program Manager, Visual Studio Tools for Office & Apps for Office

    Tuesday, November 6, 2012 11:35 PM
    Moderator
  • Thanks Michael for looking into this.

    I'm looking at the task manager. When it is running you can indeed see the garbage collector working when memory is reduced, but when it starts at 70mb it runs up to 110mb after 15 minutes.

    After 1 day it's around 1gb.

    Wednesday, November 7, 2012 9:39 AM
  • Hi Kurt,

    Thanks for posting in the MSDN Forum.

    Would you tell me your PowerPoint version for further research?

    Have  a good day,

    Tom


    Tom Xu [MSFT]
    MSDN Community Support | Feedback to us

    Friday, November 9, 2012 7:08 AM
    Moderator
  • Tom, it's 2010.

    In 2003 and older versions this was happening too. Probably PPT is remembering some information for the undo actions. But with old version you could call the SAVE function to drop the memory increase back to the initial level. But not in 2010 anymore, neither in 2013.

    Friday, November 9, 2012 10:38 AM
  • Thanks, Kurt.  I can try to take a look at this today, and will get back to you either this evening or early next week.

    Michael Zlatkovsky | Program Manager, Visual Studio Tools for Office & Apps for Office

    Friday, November 9, 2012 6:03 PM
    Moderator
  • Thanks you all. Have a nice weekend!
    Friday, November 9, 2012 6:34 PM
  • I checked with a fellow VSTO developer, and we're both fairly certain that the issue is not with VSTO, but with the underlying Interop object model.  I've contacted a few members on that team, and will let you know once I have a reply or a suggested workaround.

    Just so we're aware:  how mission-critical is this issue?  How many users is it impacting?  And what is the overall scenario that you're trying to accomplish (so we can brainstorm any alternative workaround).

    - Michael


    Michael Zlatkovsky | Program Manager, Visual Studio Tools for Office & Apps for Office

    Tuesday, November 13, 2012 12:44 AM
    Moderator
  • Thanks Michael.

    A solution to this is very critical to our software and 1000's of our clients are effected. Hope you can come up with a good solution or workaround.

    Tuesday, November 13, 2012 9:07 AM
  • I'll do my best.  I just sent a follow-up email to the PowerPoint engineering team with the information you provided above, so hopefully they'll realize the severity of the situation for you.

    While we wait:  what is the scenario / ultimate goal you're trying to accomplish?  If you'd rather not discuss this publicly, feel free to shoot me an email at michael.zlatkovsky@microsoft.com.  Even if the particular call you're trying to make is broken, there might be some alternative means that come up if we know what is is that you're trying to do, how controlled your environment is, etc.

    - Michael


    Michael Zlatkovsky | Program Manager, Visual Studio Tools for Office & Apps for Office

    Tuesday, November 13, 2012 4:13 PM
    Moderator
  • Hi Kurt,

     

    I checked with the PowerPoint Engineering team.  PowerPoint's behavior since 2007 has indeed changed to not purge the undo stack when saving the document.  For normal users, this is actually a great feature, because that way you don't have to have a conflict between wanting to save versus wanting to be able to undo.  However, this lack of undo-stack-purging, combined with a change to have multiple consecutive Object-Model calls be merged into a single undo entry, does explain the scenario you were describing.  The combined effect can indeed cause memory usage to continue to increase, if no intervening "user" edit is made to prevent further Object-Model calls from merging, or some other operation which causes the undo stack to be cleared.

     

    There are two workarounds I can suggest:

     

    1. As it so happens -- though this certainly isn't guaranteed to be the case in the future -- saving to a binary PowerPoint file (e.g, .ppt rather than .pptx) will cause the undo stack to be cleared.  I'm not sure if there are any adverse effects for saving as a binary file, though, and you shouldn't rely on this behavior continuing to be the case down the road.  E.g., I would treat it as more of a short-term solution. 
    2. Depending on how often you need to purge the undo stack, and if it's ok for the screen to flash for a second during that time, the more long-term workaround might be to have a timer/trigger that quickly closes the presentation and immediately re-opens it and re-launches the slideshow from wherever the slideshow left off.  The undo stack in PowerPoint is per-document, so if you close the document and re-open it, you should have a blank slate.  Just make sure that the instance of PowerPoint (and hence your Add-In code) doesn't close when you close the document:  that way, you'll be able to immediately re-open with little interruption.  The downside is that some screen flickering -- while the document closes and re-opens -- is probably close to unavoidable.  The question is, how quickly the change can happen, versus how long will the slideshow will be running before you need to do the swap.  If it's for 2 seconds once every few days, that might be good enough for your context.

     

    Hope this helps.  Let me know if you have further questions.

    All the best,

    - Michael


    Michael Zlatkovsky | Program Manager, Visual Studio Tools for Office & Apps for Office

    Wednesday, December 5, 2012 1:44 AM
    Moderator
  • Thanks Michael.

    I did here a quick test here by closing and opening the presentation and indeed it seems to lower the memory usage. I will try to embed this functionality in our software here. Thanks for your cooperation on this!

    Wednesday, December 5, 2012 10:54 AM