Well, truth be told- it doesn't mean it is DEFINITIVELY a memory leak. It could be that since it is a beta driver, that it is saving all the tracking information or something. But considering the program should sit at about 8 megs, it would make anyone wonder why it's using 70 megs. It doesn't APPEAR to do enough to require that kind of usage. 70 megs is rather small- if it were Doom 3 or FS9 with megascenery or photoshop. But it's just a small app to drive the TrackIR inputs, so it does seem excessive. I won't pretend to have the slighest idea how it works, so it may just be doing it's thing- but considering it works exactly the same way when using only 8 megs- it does seem like that is a memory leak. i.e. it doesn't NEED 70 megs- they may have just forgot to remove some debug code or something.Memory leaks are probably the single most common problem in software development. I wrote a client/server app to do online testing, and debugging it literally took 6 months, when the program only took 3 to write in the first place. I found seemingly unconnected, inane errors DAYS after it had been running smoothly. Things that didn't make sense AT ALL- like a variable that was set to 10 somehow changes to -500000 for no reason at all (so I thought). Tracking a bug like this can take months, and I never got it working 100%. Usually a reboot is recommended once a week. Windows programming is EXTREMELY complicated when you get into the nitty gritty. You may create a new ODBC connected database on a certain form to, for example, display a list of user names. When the user clicks the X, you can destroy the object correctly. However, if some event happens that is not related to this form, it may be closed some other way- and the object may not get destroyed correctly (which frees the memory). This is not a very descriptive example, and probably not the nastiest of situations. Many times, problems like this come from the DirectX API, or a built in API. There were many documented memory leak bugs in MS Visual Studio 6. Some of it is simply a problem that a certain API's usage is not thoroughly documented enough. I can't think of any good ones- but found when I started learning DirectX that things like- when do I release the DC handles? When do I destroy the Directsound buffers? Do I destroy the DirectX object too? Or reuse it? It's doesn't matter if you don't know what I'm talking about- I'm just trying to point out that "programmer error" is sometimes not really their fault. And a memory leak is sometimes not a "bug" in the software, but an "undocumented feature" :)

Thanks Christian, so if I understand correctly the notion that a program has a memory leak comes from the observation that a program is using an amount of memory that is greater than size of the executable(??). But without any sort of information about the specifics of the operation, I agree as you say, we wouldn't know if the allocation of resources was intended or not, since I guess the failure to release resources seems to be part of the equation. I wonder if FL390 has some special knowledge about how the program works, or is supposed to work.Thanks again everyone, I've learned alot from this thread and I appreciate your participation and information. I'm satisfied that I have a better understanding of memory leaks. Best regards.

New version of the software is out you may want to try that one?