VS 10 - Memory Leaks

GuyL · Post by **GuyL** » Mon Jun 05, 2006 3:43 pm

I've begun to use VS 10 for a few projects and it seems to be less stable than VS 9. VS9 never crashed on me and VS 10 has a few times now.

I've also experienced "out of memory" errors while working on projects which is new to me in VS 10 - also never experienced in VS 9. In the task manager, VS has grown to use almost all available RAM (I have 2 GB) over time working on a project. It seems there is a serious memory leak in VS 10.

Note - I shut down all programs and background services while doing video editing so it is basically Windows running in the background and nothing more.

jchunter · Post by **jchunter** » Tue Jun 06, 2006 2:20 am

I have to agree that 10+ is less stable then 9.0 - but maybe I am working it a lot harder. I have not experienced a memory leak - so far.

Here is a list of some of my crashes:

Mousing on timeline:
AppName: vstudio.exe AppVer: 10.0.0.0 ModName: ulppmgr.dll
ModVer: 8.0.0.0 Offset: 000024cc

5/22/06 Crash after terminating H.264 render of HD project
AppName: vstudio.exe AppVer: 10.0.0.0 ModName: uvavi.vio
ModVer: 6.0.0.0 Offset: 0003a84e

5/23/06 Crash after transcoding HD project (3 minutes) to H.264
AppName: vstudio.exe AppVer: 10.0.0.0 ModName: uvavi.vio
ModVer: 6.0.0.0 Offset: 0003a84e

Crash after creating 720x480 H.264
AppName: vstudio.exe AppVer: 10.0.0.0 ModName: uvavi.vio
ModVer: 6.0.0.0 Offset: 0003a84e

Crash after creating 1920x1080 50 minute Divx video file
AppName: vstudio.exe AppVer: 10.0.0.0 ModName: uvavi.vio
ModVer: 6.0.0.0 Offset: 0003a84e l

Crash after creating short Divx video file:
AppName: vstudio.exe AppVer: 10.0.0.0 ModName: unknown
ModVer: 0.0.0.0 Offset: 00000000

AppName: vstudio.exe AppVer: 10.0.0.0 ModName: unknown
ModVer: 0.0.0.0 Offset: 00000000

(later reinstalled Divx codec, which solved the last three problems.)

Black Lab · Post by **Black Lab** » Tue Jun 06, 2006 5:20 pm

I have not experienced crashes or memory leaks to this point.

PeterMilliken · Post by **PeterMilliken** » Tue Jun 06, 2006 7:59 pm

John's and Black Lab's response argues that there is probably only one (rather than multiple) paths through the code where VS 10 is leaking.

Is there some particulare edit operation that you are using frequently Guy?

You should be able to use the memory monitor to observe memory usage as you "exercise" each of the edit operations that you are using in your workflow - perhaps you can isolate the problem using this technique?

It could be one operation that leaks a small amount of memory each time - in which case you need to look for something that is used frequently, or it could be an operation that is used infrequently but gobles great chunks of memory with each use - the later would be much easier to find using the memory gauge

Perhaps a bit of thought as to what operations you used in your recent project might lead you to the problem area? i.e. is there something that you did that perhaps John and Black Lab may not have done in their projects/usage of VS 10?

Just some thoughts from someone who has decided this time around to let others pioneer the "gotcha's" in a new release of software

Given the frequent updates/releases to VS and how each release adds more and more features found in MSP - perhaps I'll skip this upgrade altogether and just purchase MSP - it might be cheaper in the long run (especially as the upgrade price is starting to climb)

Peter

GuyL · Post by **GuyL** » Tue Jun 06, 2006 8:43 pm

Peter,

Good thinking, I will give that a go. I can't think of anything off hand other than I've been putting the overlay tracks to work as this is the prime reason I purchased the upgrade. Also, I've been using the newer audio features of VS10 that were not in VS9. These are just things that differ from the previous version for me. It could be old features causing the issues but I'll check it out on my next project.

jchunter · Post by **jchunter** » Tue Jun 06, 2006 10:15 pm

Interesting, I have not used the overlay tracks at all except for an accidental mousing. I recall the leak in VS8, where each mouse click on the main timeline would allocate aother chunk of memory. I could cause a crash just be clicking a hundered times, or so...

Try clicking on the overlay track, while monitoring the memory usage.

Black Lab · Post by **Black Lab** » Wed Jun 07, 2006 11:31 am

I have not yet had the need to use the multiple overlays either.

davidhaynes · Post by **davidhaynes** » Wed Jun 07, 2006 9:52 pm

I have been having similar problems...
Using V10 solidly for the last 2 weeks using multiple overlays and chroma screen.
Consistently V10 crashes when I save the project as a video (MPG) file: system hangs, program closes completely or error message displayed. Usually a reboot fixed the problem.

I was creating 12 X 3 minute videos and found that rendering project after project the system became unstable - rebooting regularly every 3 or 4 projects seemed to help.

dblml320 · Post by **dblml320** » Mon Jun 12, 2006 9:06 pm

I see two types of regular crashes:

1.Crash while working within a project. I can tell when it is going to crash about 20-30 seconds before it does .. my machine starts thrashing the disk. I suspect it is growing the swap file, and for some reason VS10 cannot handle this.

2.Crash on exit. If I invoke VS10, then render a clip, then exit VS10, I get a trap on exit in HerDocdll.dll. This one is very regular .. 95% of the time after I render a clip.

GuyL · Post by **GuyL** » Mon Jun 12, 2006 10:15 pm

I have confirmed it on my end it has to do with using multiple overlays. Once you start the memory usage just starts climbing until it runs out. I've also had the experience where the disk starts thrashing and the swap file starts to grow.

There is a serious memory leak in VS10 when using overlays. However, If I use the 1st overlay track and do not enable the rest it works as did VS9.

PeterMilliken · Post by **PeterMilliken** » Mon Jun 12, 2006 11:14 pm

Sorry if this is stating the obvious

. But I get the impression that there is a lack of understanding about swap files and "disk thrashing" here.

As an application runs, it requests memory in chunks from the operating system (OS) - the amount of what is refered to as "physical" memory is limited to your RAM (and how many other applications are runing in that RAM "space"). When the OS runs out of physical memory i.e. RAM, it then starts to use "virtual memory" to satisfy application requests for more memory - this is your swap file on the hard drive. The application isn't aware that the memory allocated to each request is physical or logical (virtial), and when the application attempt to access a piece of memory that is actually in the swap file then the OS is reponsible to "swaping" the contents of the hard drive area into an area of RAM where the application can access it - and putting what was in that area of RAM into another location in the swap file on the hard disk (so it isn't "lost"). At some later stage, the application will attempt to access the memory location that was "swapped" out to disk - in which case the OS selects a portion of physical RAM, writes it out to hard disk and then reads in the memory that is trying to be "accessed" by the application - hence the "thrashing" of the hard drive as it writes out slabs of memory to the swap file and reads in other slabs. Obviously when there is a memory leak, the application will use up all available RAM and then the OS will quite cheerfully start allocating space on the hard drive. There are algorithms built into the OS that attempt to minimise the swaping (or paging as it is refered too), but no algorithm can perfectly predict the order in which an application will want to access the memory it has been allocated, so the worst case scenario is when the application calls in an area of memory, uses it briefly, then wants another piece of memory that is on disk, uses it briefly and then another piece that happens to be on disk and so on etc

Normally the swap file is recommended to be twice the amount of real memory i.e. if you have 1G of RAM then the swap file should be sized to be about 2G. This has been one of ULeads "standard" answer to some problems users experience in VS - just increase your swap file size. To my mind it is similar to your IT support person saying "just reboot and the problem will go away"

Peter

GuyL · Post by **GuyL** » Tue Jun 13, 2006 12:16 am

Peter,

As a technican PC person (Electronics Engineering Education) I understand what you are saying and that was a great explanation for those that require a non-techie explanation... Thank you for that.

Having monitored this now since I began experiencing the problem, VS10 has some memory management issues. The swap file does matter but a lot of this is myth. You can monitor the physical and virtual memory usage to see what is going on. Also, when I use VS it is basically the only app running along with the basic O/S. So what I monitor will be limited to those. What I am reporting is almost every instance of using overlays beyond the default one...the memory usuage begins to climb quickly as does the virtual memory as Windows realizes what is going on. It all leads to VS reporting out of memory. It hasn't "crashed" in the traditional sense for me. It just tells me there is insufficient memory. If I close out of VS, the memory is allocated back to windows and I can see that happening.

This is a VS problem because on the same system, I run my business daily and I am a huge multi-tasker. I am usually running one virtual pc - and sometimes 2, outlook with business contact manager (which has an instance of SQL running) and 2 to 6 other apps running too depending what I am working on. I run dual monitors and my task bar runs out of realestate pretty fast. I experience very few system slow downs (thanks to my dual core - love that invention), no virutal memory hard disk thrashing, and XP has not crashed on me in ages.

In a nutshell, I push my system hard on a daily basis and VS9 had no issues. VS10 has been another story so far...but only when using multiple overlay tracks. What would you conclude?

PeterMilliken · Post by **PeterMilliken** » Tue Jun 13, 2006 1:36 am

Hi Guy,

I agree with you

VS is definitely the culprit and overlay tracks certainly seem to be the problem area - as a programmer I know exactly how easy it is to allocate a chunk of memory and then forget to deallocate it when I have finished using it

I only jumped in here with my "virtual memory 101" course because I had the impression that it may not have been fully understood by all the posters

This forum is a regular minefield from the perspective that sometimes I am talking to people who know how to turn on the computer (and that is all) and other times I am talking to somebody who knows more than I do

So it can be difficult avoiding offending anyone.

I also have a dual-core machine (see my "System" for details) - I have only been using it for a couple of weeks but am in love with it. The dual-core made no difference between VS 10 (trial) rendering a video and VS 9 rendering the same video (despite what the web page for VS 10 states) - but with the dual-cores I was able to play a game at the same time with little or no effect on the rendering time - something I couldn't do with my previous system!

Have a good evening there,

Peter

GuyL · Post by **GuyL** » Tue Jun 13, 2006 10:10 am

Peter, as a closing note.....

I too experienced no gains in dual core with respect to VS10. So I'm not sure what they mean by their website. From what I can see it isn't multi-threaded or "optimized" in any way. And I experience the same as you do... you never know who you are talking to. So it is always better to play dumb until you know you are not the dumb one.

Post by **jparnold** » Sun Apr 13, 2008 12:27 am

I know that this post is getting old now but I just did a "google" for ulppmgr.dll which showed this post - I have been experiencing VS10+ crashes off and on (with no clear pattern) ever since I purchased it 2 years ago and it usually displays ulppmgr as the "culprit".

I have in the past started a couple of posts on "why does VS10 crash" and after reading this particular post was very interested in what users have to say.

I am not sure if my problems are related to running out of memory as I have just doubled the szie of installed ram without noting much difference however I agree that VS10+ is not good at managing memory and freeing up memory. I recently had a large project loaded and looked at the performance tab of Windows Task Manager and noted the Available Memory. I then opened a NEW project and added one single short (8 seconds) video clip and noted what happened to Available Memory - NOTHING! I would have thought that it would INCREASE.

The ONLY thing I have noticed with the regularily of crashes is that I seem to experience NO crashes when my project is SIMPLE ie. ONLY the video track is used - that it contains any number of video clips but NO transitions, split audio etc. In fact the crashes appear to increase when I do a Split audio and then 'drag' the audio (on the audio track) under a different video clip OR if I split the audio from a trimmed video clip and then expand the length of the spilt audio to the original length of the video clip which it came from so as to be also under adjacent video clips.

But what annoys me the MOST is that we never know if anyone from Ulead (now Corel) reads these posts and attempts to find the reason (debug the software) or releases warnings of what the users should NOT attempt to do with the product. It would be really great to know that we are not wasting our time documenting our problems.