Hi,I would like to have your opinion about a strage fact that araises when I try to build a release version of my XLL.In the debug release all works fine, but when I execute the build release I get Access Violation Errors and I don't know how to find the place where the error occurredany ideaaudetto

The compiler does some different thing to your code when compiling in release mode that can potentially screw up your codeThe most likely problem is that you've got an uninitilazed pointer that is NULL in debug mode but isn't in release mode but assuming you get a clean compile with warnings set to 3 or above or at least you understand each error, here is roughly what you need to do.1) Turn off all optimizations in C++, retest if it now works you've got an optimization problem. These can be quite complex so if then happens just reply here.2) If it still doesn't work then you want find the exact location of the problem and you can do this with the help of map file which you can create off the link tab.To use the map file you need to know the location of the code at the time of the crash, the easiest way is probably to try and debug the xll within excel within MSVC using the release build and looking at the call stack when the crash happens. Then you lookup the address inside your xll in the map to find out what function you're in (this doesn't work as well if you're xll gets rebased which is one good reason why you should ensure your code isn't rebased)Once you've find the location then you usually can work out what's going on. You can sometimes even work out the values of some relevant variables using the register values at the time of the crash.John

All sound advice.There are actually rather more programs than you might think that only work when compiled in debug.John's map stuff is fine, thugh low level enough to not be very friendly.You may choose to trace your code with something like, in your main() functionfp=fopen("C:\\tracebug.txt","w");where FP is a globalFILE *fp;In stdafx.h#define TRACEWHERE(line,file) fprintf(fp,"%d %s\n",__LINE__, __FILE__);fflush(fp);You can sprinkle this through your code, and find out the last line before it dies.When you've finished, simply #define TRACEWHERE(line,file)will leave nothing behind when you recompile.That being said, I'd bet money that your stuff dies "before" or "after" main has started or as the program exits.

audetto,In debug mode VC++ initialises the memory used to store all static (global) variables to zero; in release mode it leaves the memory as it finds it. The symptoms you describe sound like you aren't properly initialising some variable or pointer.There are tools which can be purchased (but at the moment I can't recall their names) which when linked in, override the default debug mode initialisation and set the memory to some non-zero hex pattern (like 0xDCFC ) to help detect these missing initialisations.Jim

it's an optimization error.........I've set in MSVC++ in the optimisation tab "Disable (Debug)" and now my code works very well?what could I do?thankaudetto

AudettoOK good, so the next step is to find which of the optimizations is causing the problem and then either just turn off that optimization or find the bit of code that's causing the problem and wrap it with pragmas to turn off that optimization locally.To find out which optimation is causing the problems you need to set the optimize settings to custom and match the custom settings to the ones specified by the default set you're using and then turn the optimizations off one by one and see which one reintroduces the problem. To find out what options are meant by say minimize size you need to dig quite deep into the MSVC documents look under "/O1, /O2 (Minimize Size, Maximize Speed)" under compiler reference and that will tell you what custome settings are being used.Alternatively you just disable optimizations for this xll and just remember to tell everyone why you've done that.My bet is "assume no aliasing" is the one that's causing the trouble.Also I think Jim if referring to NuMega's BoundsChecker which is a very handy thing to have access to for other problems.

I did it and it seems that the bad option is "Frame-Pointer Omission" /OyNow, I would like to remove this option not from the entire project but only from some file using #pragma ...but I don't know how to find the point where there is the error. I tried to look at the map file but it is not so easy to look at... And may be the cause of the error is elsewhere thant the point where it occursbyehave a nice week-endaudetto

AudettoNever seen that one be a problem before wierd...To try and isolate the problem you'll need to wrap code in #pragma optimize( "y", off )...#pragma optimize( "", on ) To turn that franme pointer thing off for all code inside. Are you using SEH and C++ exception pointers?John

AudettoJust remembered something, I think I've seen this before when I've accedentally overwritten stack memory. I think the stack is protected under debug builds and there is a class of bugs that will work except under the frame pointer optimization. I think BoundsChecker will help with this sort of thing if that's the problem. Otherwise look for this sort of thingchar Test[3];Test[3] = '\0';John

A lot of exceptions.I mean: I use a lot of "throws", "try" and "catch". Could it be a problem?

What is BoundsChecker?

QuoteOriginally posted by: audettoA lot of exceptions.I mean: I use a lot of "throws", "try" and "catch". Could it be a problem?I saw something about the combination of SEH and C++ exceptions, so using one shouldn't be the problem.QuoteOriginally posted by: audettoWhat is boundschecker?See http://www.compuware.com/products/devpa ... nds.htmI'd bet that someone in your IT dept has access to a copy and can run your stuff through it and see if there are any problems.John

I had a similar problem a while back caused I think as follows1. I had static string constants I was using to register the Excel functions2. To pass these to Excel they had to be Pascal-style with count at start so I left the first char blank in the constant & inserted the count on the fly. 3. Behaviour of static data when written to 'undefined' & at some point new VC++ release caused errors in Release build due to this.Solution was to copy static data to temporary vars before counting then register with these.

Since you handle all exceptions (with catch (...)) it is hard to know where the error occured; you also must include debug info in the release (project settings->c++ AND Link->generate debug). It does not slow the program.Then debug the program , and in debug->exceptions choose "stop always" for the relevant exception (usually microsoft c++ exception)QuoteOriginally posted by: audettoA lot of exceptions.I mean: I use a lot of "throws", "try" and "catch". Could it be a problem?