DLL Compatibility?  
Author Message
Pat.





PostPosted: Visual C++ General, DLL Compatibility? Top

I am converting an app from vc6 to vc8 (vs2005). I've got everything to compile fine, and most of the testing looks good. While system testing in Release mode, I get an occasional crash.

The dialog box says "PCSMain.exe has generated errors and will be closed by Windows. You will need to restart the program. An error log is being created".

Even though I have drwtsn turned on, I don't see any error logs being created. Even while running the app thru VS de****, I don't get any helpful info when it crashes.

I am taking a wild guess that the problem may be a library issue. Since I am using vc8, msvcr80.dll is used. But in looking at depends.exe for my exe, it looks like my db2 stuff also depends on msvcr71.dll.

So my question is: Can msvcr80.dll and msvcr71.dll work together, or are they stepping on each other somehow and creating my error

btw, this crash only happens in Release mode, not Debug mode.

Thanks,

Pat




Visual C++13  
 
 
Ben Anderson MSFT





PostPosted: Visual C++ General, DLL Compatibility? Top

If you didn't recompile parts of your app, and they are passing different versions of the same classes back and forth between the parts, you will almost definitely run into problems. Make sure you aren't missing part of your app when you recompile (like a dll or lib).

-Ben



 
 
nobugz





PostPosted: Visual C++ General, DLL Compatibility? Top

You might get a dependency on msvcr71.dll if you link to a DLL made by VS2003. That's pretty normal and ought to work properly. Your only shot at troubleshooting this problem is to get a call stack in the de**** when the app crashes. If you converted the project from VS6, the release configuration might not generate debug symbols.

Choose Project + Properties and select the release mode configuration. C/C++, Debug information format = /Zi. Linker, Debugging, Generate debug info=Yes. Now run the release version with the de****: Build + Configuration manager, Active=Release. Build + Rebuild Solution. Debug + Start debugging. Upon the crash, Debug + Windows + Call stack.


 
 
Pat.





PostPosted: Visual C++ General, DLL Compatibility? Top

That is what I'd love to do. The problem is that this crash only occurs on pc's without VS 2005 installed. I cannot reproduce it on my development pc. That makes me think that a dll is missing or something. But what is wierd is that the crash only occurs when I repeat a particular scenario a 2nd or 3rd time. It does work the first time. So this tells me that I must have all necessary dlls available.

 
 
Pat.





PostPosted: Visual C++ General, DLL Compatibility? Top

I have a separate program that rebuilds my whole app, so I'm sure that I'm doing that. I do have a db2 database on an AIX machine, so I do reference db2 dlls and libs that are out of my control.

 
 
nobugz





PostPosted: Visual C++ General, DLL Compatibility? Top

You mentioned running the app through the VS de**** in your original post. Anyhoo, I've had a similar case quite a while ago and used Debugging Tools for Windows to get a call stack. I'm fuzzy on the details right now but there was a large VB-script that you could use to start the app and get a walkback after it crashes. Make sure you copy the .pdb files to get it to use the symbols. The symbol packages are handy too if it crashes inside the bowels of Windows.

Last but not least, be weary of DLL hell. Good luck.




 
 
Pat.





PostPosted: Visual C++ General, DLL Compatibility? Top

Exactly, I am very weary of dll hell. But I never know where to start in those cases. I'll try to get that call stack first and see where it takes me. Thanks.

 
 
Ben Anderson MSFT





PostPosted: Visual C++ General, DLL Compatibility? Top

What sort of redist mechanism are you using to put the VC DLLs on your target machines

Have you built a setup project in VS to autodetect which dll msms out to be included



 
 
Pat.





PostPosted: Visual C++ General, DLL Compatibility? Top

1) My app is an in-house app, so we don't install it on each machine. We just put it in one folder on a network drive for everybody to access. All needed dlls are included in this application folder.

2) As far as which dlls to include, that is purely a manual, hit or miss process until we get it right. We don't have a setup project for autodetect. How does that work

I assume the problem can't be a missing dll because the crash only happens when I repeat a scenario multiple times. If a dll were missing, I assume it would have a problem immediately. So it kind of sounds like mismatched dlls or misaligned memory or something like that.

I know my questions are a bit vague right now, but I'd be more specific if I could actually drill down to get more details somehow. So maybe my question is 'what questions should I be asking '.

The app is a standard non-managed c++, mfc app that is very stable in the vc6 environment.



 
 
Pat.





PostPosted: Visual C++ General, DLL Compatibility? Top

I went into 'Event Viewer - Application Log' to see if the crash registered there. This is the entry I found:

The description for Event ID ( 0 ) in Source ( .NET Runtime ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. The following information is part of the event: Shim database version C:\WINNT\Microsoft.NET\Framework\v2.0.50727 doesn't have a matching runtime directory.

What does this mean My app is a standard Windows C++ app, with no web services involved.



 
 
nobugz





PostPosted: Visual C++ General, DLL Compatibility? Top

http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=131584&SiteID=1&PageID=1



 
 
Pat.





PostPosted: Visual C++ General, DLL Compatibility? Top

This looks like a different message. Mine says

Shim database version C:\WINNT\Microsoft.NET\Framework\v2.0.50727 doesn't have a matching runtime directory.

The one referenced in the previous link says

Unable to open shim database version registry key - v2.0.50727.00000.

But I will check on these permissions just in case.



 
 
Ben Anderson MSFT





PostPosted: Visual C++ General, DLL Compatibility? Top

I assume you have installed the 2.0 .Net Framework on your target machines

As for auto-detecting dependencies, it appears it may not work exactly as I thought (it may simply detect project dependencies). A good place to look for understanding dependencies would be:

ms-help://MS.MSDNQTR.v80.en/MS.MSDN.v80/MS.VisualStudio.v80.en/dv_vccore/html/62a44c95-c389-4c5f-82fd-07d7ef09dbf9.htm

Using the tool depends.exe on your dll should give you a good idea of the required DLLs (look for the ones ending in "80").

Another important thing to note is that the 2005 dlls are set up not to load unless your application contains the appropriate manifest for the means by which you are trying to load them. So if you're leaving the dlls on a network share, be sure that your manifest is set up correctly for app-local deployment. Here is the article on private assemblies:

ms-help://MS.MSDNQTR.v80.en/MS.MSDN.v80/MS.WIN32COM.v10.en/sbscs/setup/assembly_searching_sequence.htm

Finally, be aware that security restrictions on .Net assemblies do not allow execution over the network (at least by default). I'm not an expert in .Net so there may be a way to disable this. Unless you are compiling anything /clr, or are dependent on managed code this should not be an issue though.

Good luck.

-Ben



 
 
Pat.





PostPosted: Visual C++ General, DLL Compatibility? Top

Thanks for the response, Ben.

Here's a stupid question. Do I need the .Net framework installed on every target machine 1) We run the app from a network drive folder. 2) All necessary dlls are in this network drive folder (at least that's the goal). 3) The app is purely a non-managed standard C++ app with no web services or anything like that. It is purely a standalone Windows app that was written before .Net even existed.

Currently, the .Net framework is not on any of my target machines. What would happen in this case Wouldn't I see errors right away I ask this because the crash comes only after I update/save a field multiple times. The first 5 times I update/save a field to the database, it works fine. Then around the 6th or 7th time when I update/save it, it crashes. All other unit and system testing of the app seem to be fine, though it hasn't been put thru a real stress-test.

Same question for the manifest being set up for app-local deployment. If I don't have this set up, wouldn't errors pop up right away, not after multiple iterations of the same processing



 
 
Ben Anderson MSFT





PostPosted: Visual C++ General, DLL Compatibility? Top

The debug error you are getting is certainly in reference to .Net. If your app is non-managed, perhaps this is an error related to the debugging you are trying to do Maybe it is in some external dependency of your program

I agree that it seems like any missing dependency should give you an error/immediately though.

Perhaps your app has a memory leak or is trying to reference memory that has already been freed There were changes to the heap so that dynamically allocated memory that has been freed is reused much more quickly. There were some relatively large vendors that used to have bugs in their code where they were re-deleting an already deleted pointer which, when the heap was less efficient, didn't have an effect because the second delete came soon enough in execution that there wasn't anything dropped back in the same spot yet in earlier versions of VC, but when they were upgraded to the new heap (which is more efficient and reuses freed memory more frequently) became real problems because they started doing **** things and corrupting memory.