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

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

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

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.

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

This looks like a different message. Mine says

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

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

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.