System.InvalidCastException: QueryInterface for interface ... erro

[=?Utf-8?B?RCBKYXJ2aWU=?=]

A VB.NET 2003 application accesses a custom VB 6 DLL. It has run successfully
several months, and has been modified without problem a few times during that
period. Recently another set of changes were made to both the VB.NET code and
the DLL. The new version was successfully installed on our production server,
and ran without problem for 2 weeks until a scheduled reboot of the server
occurred. Since the reboot, the application always fails with the following
exception messages whenever the DLL is accessed. As far as can be
ascertained, no patches or further changes were applied either to the
application or to the server between installing the application and the
subsequent reboot.

The DLL in question is CmCalclib2.DLL, and PIACE.BaCPM.Compressor is defined
in VB.NET code.

Error: ---System.InvalidCastException: QueryInterface for interface
CmCalclib2._Compressor failed.
at CmCalclib2.CompressorClass.set_Config(CMCompressor )
at PIACE.BaCPM.Compressor.InitialiseCompressor()
--- End of inner exception stack trace ---
at PIACE.BaCPM.Compressor.InitialiseCompressor()
at PIACE.BaCPM.Compressor.ACECalculations()

The program still runs successfully on a development server under the
debugger. There do not appear to be any security issues to prevent the DLL
being executed by the application (and in any case, no configuration changes
were made when the server was rebooted).

[Grok]

Sounds like one problem with two symptoms. I would bet on someone
breaking compatibility in CmCalclib2.dll two weeks (or more) earlier,
but it did not become evident on the server until the reboot because
the old version was cached.

Check your new CmCalclib2.dll interface GUIDs, make sure they match
the old version. If they don't, go back and recompile CmCalclib2.dll
with binary compatibility and redeploy, reboot.

If you don't care about maintaining compatibility, (no other
application is using CmCalclib2.dll), just unreference and rereference
CmCalclib2.dll in your VB.NET project references.

[=?Utf-8?B?RCBKYXJ2aWU=?=]

You are right - the change to CmCalclib2.dll did break binary compatibility.
The application in question is the only application to use it. I have already
unreferenced and rereferenced the DLL and rebuilt and reregistered the DLL,
and rebuilt and reinstalled the VB.NET project, more than once in an attempt
to fix it, but it hasn't helped. (The production server has not been rebooted
again - but you don't appear to say that rebooting is necessary if
compatibility doesn't have to be maintained.)

[Cor Ligthert[MVP]]

D,

Option strict is set to on in the top of your code?

Cor

"D Jarvie" <ja***@newsgroup.nospamschreef in bericht
news:19**********************************@microsof t.com...

>A VB.NET 2003 application accesses a custom VB 6 DLL. It has run
successfully
several months, and has been modified without problem a few times during
that
period. Recently another set of changes were made to both the VB.NET code
and
the DLL. The new version was successfully installed on our production
server,
and ran without problem for 2 weeks until a scheduled reboot of the server
occurred. Since the reboot, the application always fails with the
following
exception messages whenever the DLL is accessed. As far as can be
ascertained, no patches or further changes were applied either to the
application or to the server between installing the application and the
subsequent reboot.

The DLL in question is CmCalclib2.DLL, and PIACE.BaCPM.Compressor is
defined
in VB.NET code.

Error: ---System.InvalidCastException: QueryInterface for interface
CmCalclib2._Compressor failed.
at CmCalclib2.CompressorClass.set_Config(CMCompressor )
at PIACE.BaCPM.Compressor.InitialiseCompressor()
--- End of inner exception stack trace ---
at PIACE.BaCPM.Compressor.InitialiseCompressor()
at PIACE.BaCPM.Compressor.ACECalculations()

The program still runs successfully on a development server under the
debugger. There do not appear to be any security issues to prevent the DLL
being executed by the application (and in any case, no configuration
changes
were made when the server was rebooted).

[=?Utf-8?B?RCBKYXJ2aWU=?=]

Option Strict is set to on. I also saw some comments on the internet about
turning it off, so I tried that as well, but it didn't help.

[Cor Ligthert[MVP]]

D,

That it does succesful run in the debugger does not mean that everything is
correct.

Did you already set the references again to be sure that you are actually
pointing to the same DLL/s

Cor

[Grok]

It would need to be rebooted, for the same reason the problem did not
show up for 2 weeks after your changes. The previous CmCalclib2.dll
is still in cache despite you copying a new version to the server.

On Tue, 18 Dec 2007 09:36:09 -0800, D Jarvie <ja***@newsgroup.nospam>
wrote:

>You are right - the change to CmCalclib2.dll did break binary compatibility.
The application in question is the only application to use it. I have already
unreferenced and rereferenced the DLL and rebuilt and reregistered the DLL,
and rebuilt and reinstalled the VB.NET project, more than once in an attempt
to fix it, but it hasn't helped. (The production server has not been rebooted
again - but you don't appear to say that rebooting is necessary if
compatibility doesn't have to be maintained.)

[Walter Wang [MSFT]]

Hi,

You may also check the interop assembly (generated by Visual Studio when
you add reference to a COM component and copied to your output directory),
it contains the interface ID of your COM component. You can use Reflector
(http://www.aisto.com/roeder/dotnet/) to open it and check if the GUIDs are
correct. You can use Oleview to view your VB6 COM component to determine
correct GUIDs.

Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

[=?Utf-8?B?RCBKYXJ2aWU=?=]

"Grok" wrote:

It would need to be rebooted, for the same reason the problem did not
show up for 2 weeks after your changes. The previous CmCalclib2.dll
is still in cache despite you copying a new version to the server.

Is there no way to update the cache other than rebooting? Rebooting the
production server has implications for other processes, and is not something
which can be done lightly.

[Grok]

Yes. You need to unload the process which loaded CmCalclib2.dll.

You can use Process Explorer from SysInternals to locate which process
has it loaded. If as you say only one process uses it, just exit
that. If that one process is a website on IIS5 or IIS6, and your IIS
is configured for separate application spaces, simply unload that
website. I think you're out of luck if it's IIS4, you'll have to stop
IIS and restart. But server does not require rebooting.

In any event, End Process will do the trick in Process Explorer. Once
the process using CmCalclib2.dll is unloaded, you can start it back up
and it should grab the new, correctly-referenced version.

On Wed, 19 Dec 2007 03:23:02 -0800, D Jarvie <ja***@newsgroup.nospam>
wrote:

>"Grok" wrote:

>It would need to be rebooted, for the same reason the problem did not
show up for 2 weeks after your changes. The previous CmCalclib2.dll
is still in cache despite you copying a new version to the server.

Is there no way to update the cache other than rebooting? Rebooting the
production server has implications for other processes, and is not something
which can be done lightly.