Gebe,
The scenario of memory leaking should be enough for their staff to do a full shakedown of the code. It is the one constant in all of this. This type of bug is notorious for not being able to be duplicated by the customer, because it is affected by outside influences that the customer has no way of knowing about.

Let me see if I can explain this in layman's terms...

There is the Windows Hotel, a plush resort that VuePro customers love so much, that when they find it, they just want to stay forever. Now the hotel also caters to other customers as well and at any given time, there is a random number of people staying in the hotel, because most check in and out, making room for new people. VuePro people don't leave though, and so as more come, they fill up the hotel, making it more difficult for other people to book rooms. But as long as there is room at the Inn, everyone is happy to be staying there. Mr. Undo came in and found a room no problem. Mr. Undo decided he wanted another room, after not clearing out of his first room. He finds there is no room at the Inn, even though his travel agent told him there was. He goes down and fights with the front desk, but there is no room, so there is nothing that can be done. Instead of just giving up the room, he blows the place up in anger.

Now in computer terms, it means that if a resource cannot be allocated into the reserved space and that refusal is not properly dealt with, it's going to crash. It may not even be VuePro that instigates the crash, but VuePro is the cause of it nonetheless, because it does not clean up it's allocations as it's supposed to and this is called a leak.

I've been in software development for 20 years and seen many different scenarios where there comes into play, and it's not uncommon (especially in windows). But it's nothing that the customer can share. It's not an easy bug to find, taking a complete shakedown of the code. But it's necessary if their goal is to make a stable system.

The reason it doesn't crash on a dedicated computer is because the resource table can then be used almost exclusively by VuePro, giving it plenty of leeway to leave bits on the stack. By the time it fills up enough to crash, your session with it is probably over, thus you never notice it. Also I've noticed that most people that seem to run VuePro fine, tend to stick with what is in VuePro rather than a whole lot of Poser imports and things, so it's possible the leak is only in those routines, and thus it hardly ever leaks memory in other areas.

So is it the official word from e-on that unless we can give them a duplicatable scenario that we are out of luck? If so, I would like to hear that from e-on directly. I would hope that is not the case though, as I know if I tried to pull that on my customers at work, I'd be fired.

ShadowWind