"Pure Virtual Function Call" Runtime Error Message

Hello!

I'm experiencing a rather weird error. While executing the following piece of C# code, after some 4000 up to 80000 loop iterations a popup error message is shown:

Microsoft C++ Runtime Library:
R6025 - pure virtual function call,

and after that, execution is terminated. The popup seems to be generated while execution is at the line marked with the asterisk. Note that I'm writing C#, and every of my attempts to force a "virtual function call" runtime error in a C# scratch program was either detected at compile time, or the bad call was automatically wrapped to the implementing class ...


// DmsDatabase is a valid IManDatabase object
//
IManUsers allUsers = DmsDatabase.SearchUsers("", imSearchAttributeType.imSearchBoth, true);
[...]
IManUser userObj = null;
try {
    userObj = allUsers.ItemByName(someUserName); // (*)
} catch (Exception) {
    userObj = defaultUserObj;
}

My program is a console application only; so, no GUI parts stem from my code.

Has anyone ever seen or heard something similar, or even a hint what I should look after? It seems to me that this error might originate from the IManage API ...

Any help would be appreciated!

Regards
Wolfgang

Find more posts tagged with

Comments

guido1

just a guess, but seeing as you're repeatedly referencing a new instance of a COM object (e.g. IManUsers and IManUsers) from the .NET framework you may want to call the Marshal.ReleaseComObject method on those COM objects that you no longer have use for in each cycle of your loop.

Additionally, you may want to call this method on your object in a loop to double check that the reference count on this COM object is zero (or less) to be sure that it is properly disposed of.

For version 2.0 of the framework, you should use Marshal.FinalReleaseComObject which accomplishes the same task

wolfgang

Thank you for the hint. I'll give it a try and let you know what happens ...
Wolfgang

wolfgang

Well, I've added Marshal.FinalReleaseCOMObject() calls as I found them apporpriate, but unfortunately, the errors keep popping up, without any pattern that I would be able to recognise.

I've temporarily started working around this by adding a possibility to restart my job at the appropriate spot. I'll keep you informed in this place if I find any new information about this.

dopey

You may want to simplify your code by calling Database.GetUser. If the user is in memory it won't make a server call, though searching users each time will do so.

wolfgang

Good idea! Why haven't I been using the

GetUser()

method? I can't say. Maybe I didn't see it in the list of available methods ...

Anyway, those "Pure Virtual Function Call" errors seem unimpressed :-(

wolfgang

Long time, no post ...

In the meantime, I have worked around this using kind of a watchdog approach and aside from that, ignored the problem.

Having fixed many other little cute enhancements of my script, the "Pure Virtual Function Call" seems to occur less frequently. But at the same time, I've seen other applications, e.g. Outlook, pop up the same error message box, so I tend to believe the error lies in some deeply buried Windows library. Sigh ...

Wolfgang

wolfixx

Hi Wolfgang,

I know that your posts are nearly 2 years old but have you found a real solution for that issue?

I am having having exactly the same issue in on of my tools which exports documents from Interwoven, but only if I run the export in a separate thread.
It seems that there is some issue with the Interwoven Imanage.dll library when used with the .Net framework.

Regards,
Wolfgang

wolfgang

Unfortunately, there's nothing new to this by now.
Wolfgang

wolfgang

We have been able to reproduce Pure Virtual Function Call Errors without any piece of my own software and without any piece of .NET at all.

We've been using Interwoven's NRL.exe to export a bunch of documents that we were only given the NRL link files of. You can then pretty quickly click OK buttons, and pretty regularly you get a Pure Virtual Function Call doing so.

That's not much of a solution, more of the opposite. Anyway, it shows me that there might be not much---if anything---that I could change in my code to avoid them.

Regards,
Wolfgang

wolfixx

have you logged that with Interwoven Support?
The easier this can be reproduced the better. I think we need a solution because this error will appear again in other tools / projects.

The NRL.exe doesn't seem to be a .NET assembly and I thought that the .Net Interop.Imanage.dll Wrapper was the trouble maker.

That you now get the error in that simple way is even worse.

Regards,
Wolfgang