Release build crashes

One that got me was when my partner embedded functional code in an ASSERT statement.  Make sure none of the conditional code which is ommitted in a release build is critical.  It might look somethink like this:

LPSTR lpPointer;
ASSERT( lpPointer=MyGetPointer() )
lstrcpy(lpPointer,"Data");

Note that the function is called during a debug build, but not in a release build.  Good luck to you.

1. Try turning all optimizations off for the release build. If that works, turn them back on one at a time.

2. Try using BoundsChecker on your app. We've had a few situations where the debugger was being forgiving about some dumb mistakes and then when we made a release build...BOOM! Bounds checker helped in a couple of those situations.

3. As jstolan said, all ASSERT statements that have code that you want to execute in release build should be changed to VERIFY

A compiler optimization bug is the least likely cause of a crash that happens only in release builds. Bad code is by far and away the most likely cause.

To resolve the problem, you should add symbols to your debug build, and then debug the release-mode build. You'll probably want to add an additional build target to your project for these changes.

.B ekiM

That doesn't seem to work, because the program is crashing inside MFC code, and I don't quite know why. One problem I had seen before was that before passing an argument to SetWindowText(), the argument was fine, but once it entered the function, suddenly the argument had garbage in it. I susupected that I'm linking the wrong libraries, but can you see anything wrong with these:
Linking...
Searching Libraries
    Searching f:\accusoft_static\Gear32ps.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\version.lib:
    Searching C:\Program Files\DevStudio\VC\MFC\lib\nafxcw.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\libcmt.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\kernel32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\user32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\gdi32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\comdlg32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\winspool.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\advapi32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\shell32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\comctl32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\uuid.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\oledlg.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\ole32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\oleaut32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\urlmon.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\odbc32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\odbccp32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\OLDNAMES.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\libcimt.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\WININET.LIB:
    Searching C:\Program Files\DevStudio\VC\LIB\libcpmt.lib:
    Searching f:\accusoft_static\Gear32ps.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\version.lib:
    Searching C:\Program Files\DevStudio\VC\MFC\lib\nafxcw.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\libcmt.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\kernel32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\user32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\gdi32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\comdlg32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\winspool.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\advapi32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\shell32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\comctl32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\uuid.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\oledlg.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\ole32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\oleaut32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\urlmon.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\odbc32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\odbccp32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\OLDNAMES.lib:
Done Searching Libraries
   Creating library F:\vob_glf\imaging\src\plugins\debug/NPBTIF32.lib and object F:\vob_glf\imaging\src\plugins\debug/NPBTIF32.exp
Searching Libraries
    Searching f:\accusoft_static\Gear32ps.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\version.lib:
    Searching C:\Program Files\DevStudio\VC\MFC\lib\nafxcw.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\libcmt.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\kernel32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\user32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\gdi32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\comdlg32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\winspool.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\advapi32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\shell32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\comctl32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\uuid.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\oledlg.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\ole32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\oleaut32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\urlmon.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\odbc32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\odbccp32.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\OLDNAMES.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\libcimt.lib:
    Searching C:\Program Files\DevStudio\VC\LIB\WININET.LIB:
    Searching C:\Program Files\DevStudio\VC\LIB\libcpmt.lib:
Done Searching Libraries
Creating browse info file...

NPBTIF32.dll - 0 error(s), 1 warning(s)
 I don't.
Thanks.

I have discovered one possible problem. I'm calling CreateEx to create a derived object from CFrameWnd. I've had NULL in the classname, but the help says to absolutely not do this. So what should it be?

You can figure out why the crash is happening by debugging. I'm sorry you don't like that answer, but that's how programmers solve problems in their code: debug them.  Look at the stack trace: are you passing bad arguments to MFC, or making some calls out of order?

The list of libraries you're touching seems normal; I don't recognize the one named Gear32ps.LIB, but I suppose it's some 3rd-party thing.

If you read help, you'll see that it also says you should pass a registered class name for the lpszClassName parameter to CWnd::CreateEx().

Good luck with your project. When you have questions about the debugger, make sure you let us know!

.B ekiM

Yes, of course I have to debug! Yes, Gear32ps.lib is third party, I should have mentioned that. I know I have to pass a registered class name to CreateEx, but I'm asking aren't there predefined class names you can use instead of calling RegisterClass() yourself? i.e. "CEDIT"?
Thanks.
-Ben

Okay, started doing some debugging. The program is crashing in
void* CMapPtrToPtr::GetValueAt(void* key) const, and I can't figure out why. Here's the call stack if it'll help:
CMapPtrToPtr::GetValueAt(const CMapPtrToPtr * const 0x001e040a {CMapPtrToPtr}, void * 0x0137586e) line 179
CWnd::AttachControlSite(CWnd * const 0x001e040a {CWnd hWnd=???}, CHandleMap * 0x01371909) line 426
CWnd::FromHandle(HWND__ * 0x01372c36) line 296

CWnd::OnWndMsg(CWnd * const 0x001e040a {CWnd hWnd=???}, unsigned int 32, unsigned int 1967082, long 20626896, long * 0x0012fd9c) line 1778

CWnd::WindowProc(CWnd * const 0x001e040a {CWnd hWnd=???}, unsigned int 32, unsigned int 1967082, long 33554433) line 1555 + 28 bytes

AfxCallWndProc(CWnd * 0x01411d00 {CImageWnd hWnd=0x001e03ea}, HWND__ * 0x001e03ea, unsigned int 32, unsigned int 1967082, long 33554433) line 220

AfxWndProc(HWND__ * 0x001e03ea, unsigned int 32, unsigned int 1967082, long 33554433) line 371

USER32! 77e71ab7()

USER32! 77e71a77()

NTDLL! 77f7624f()

MFC40! 5f801ce8()

From the above it obviously looks like the CWnd pointer passed is not a window???Are U sure it is in the CMapPtrToPtr::GetValueAt call, I thinkit is the AttachControlSite call, because I do not think  GetValueAt calls it??? It maybe that the pointer mapped is not a window, which leads back to the place where U say U created a NULL classname window, which may be the cause??? WHy don't U try giving it a classname?? U can use preregistered classes, they are EDIT, BUTTON and so on... see documentation for CreateWindow inthe Win32 api help.

All the best.

Try Passing 'AfxFrameOrView' for the class name to CreateEx
If I remember right , that's the name MFC uses for window class
registration for a frame window.
But it is not advisable to use that .

Gopal

I treid using AFX_WND and AFX_WNDFRAMEORVIEW and #include<afximpl.h> and as a result my window wouldn't "create()". Heh.....is there any way to strip the debugging info  
to make my executable smaller with doing a realease build with the release libraries?
I would like to solve this problem....but I just can't seem to figure out why Debug build would mask this if it were such a big problem.

This may be irrelevant but one cause of release mode v. debug mode problems may be uninitialized variables.  Debug code will initialize the variables to 0, whereas debug code will not.

Another problem  may be scribblers.  The debug code will (as part of its debugging) store memory differently.  I had a case where I was overwriting a buffer but only in release mode did it overwrite into one of my other variables, causing all sorts of hell.

As is apparent from my call stack above, some window was sending something and the window didn't appear to have a proper hWnd associated with it. I just can't seem to find that window even using Spy++.
You see, this app (actually a dll) is a netscape plugin. It has two modes. One opens a window in the netscape client area and the other creates a "floating" window, whose parent is the desktop. (NULL passed in for parent.) The first mode can also display these floating windows when a button is pressed. When I run this thing in the first mode, the netscape window acts fine, but as soon as I try to create that floating window, it crashes. Actually, the window comes up fine. I see it plain as day for a few seconds and then that pesky Access Violation occurs. Funny thing is, in this mode there is no missing handle, but it still crashes:
CMapPtrToPtr::GetValueAt(const CMapPtrToPtr * const 0x0041032c {CMapPtrToPtr}, void * 0x01375899) line 186 + 14 bytes
CWnd::AttachControlSite(CWnd * const 0x0041032c {CWnd hWnd=0x244cff66}, CWnd * 0x0137586e {CWnd hWnd=0x2574c085}) line 438
CWnd::AttachControlSite(CWnd * const 0x0041032c {CWnd hWnd=0x244cff66}, CHandleMap * 0x01371909) line 426
CWnd::FromHandle(HWND__ * 0x01372c36) line 296
CWnd::OnWndMsg(CWnd * const 0x0041032c {CWnd hWnd=0x244cff66}, unsigned int 32, unsigned int 5178090, long 20626896, long * 0x0012fb20) line 1778
CWnd::WindowProc(CWnd * const 0x0041032c {CWnd hWnd=0x244cff66}, unsigned int 32, unsigned int 5178090, long 33554433) line 1555 + 28 bytes
AfxCallWndProc(CWnd * 0x01898010 {CChildViewerWnd hWnd=0x004003f2}, HWND__ * 0x004003f2, unsigned int 32, unsigned int 5178090, long 33554433) line 220
AfxWndProc(HWND__ * 0x004003f2, unsigned int 32, unsigned int 5178090, long 33554433) line 371
USER32! 77e7288d()
Ideas? Questions? Comments? You know how to reach me.

danny_pav: debug builds don't initialize uninitialized variables to any particular value. You're completely wrong.

.B ekim

Uh, why are you loading MFC40.DLL if you're using VC++ 5.0?  Having two different versions of MFC in your process is almost always bad news. And VC++ 5.0 doesn't support MFC 4.0; it supports MFC 4.23.

.B ekiM

Uh, that's one darn good question. I'm statically linking into MFC, so why do you suppose I'm loading MFC40 ?

It looks like you don't understand what debug and release builds are all about, Betachon.

A debug build is to be used during development. It includes lots and lots of extra code designed to help developers detect and find problems. It doesn't include optimizations, so that debugging is easier. It includes symbolic information that enables the debugger in the first place.

A release build has full optimization and doesn't include any aid code for the programmer.

During the development cycle, you should frequently build and test release builds. Releas builds are different, and therefore won't exhibit all the same behaviour as a debug build--though they're incredibly close.

You shouldn't "reduce the size of your DLL by doing a release build". You should've been building and testing release builds ocassionally throughout your developmnet cycle. You can't redistribute debug builds of programs built with MFC or the Visual C++ C Runtime Libraries: the licensing agreement forbids it.

.B ekiM

Noted, sir. A terrible oversight on my part. One which will not be repeated.
On another note, do you think this MFC40... being loaded could be part of the problem?

Oh, nevermind about that MFC40... thing. I believe Netscape is the one loading it, not my DLL.

The line in your call stack that says:

AfxWndProc(HWND__ * 0x001e03ea, unsigned int 32, unsigned int 1967082, long 33554433)

means that the window with handle 0x001E03EA is receiving message number 32. Message 32 is WM_SETCURSOR.

The next two lines in the stack trace indciate that MFC is handling the message very normally: it's called OnWndMsg() to dispatch the message, and as a part of that dispatch code has called FromHandle() to get a CWnd pointer from the HWND Windows says should receive the message. This is the brunt of MFC: relating C++ objects to non-C++ objects so that object-oriented programmers may get on with life against a non-OO system API.

As any MFC book will tell you, MFC finds the C++ pointer for a given handle object by looking in a map. If you read the code with the call stack in hand, you'll see that MFC followed a path where it _didn't_ find an existing C++ object in its map, so it created a temporary one. In creating a temporary C++ object, it's setting up the C++ object to contain OLE Controls.

Each OLE Control containment-enabled object has a control site associated with it, and that control site needs to refer to the parent window's single site object. MFC walks the window map to understand which windows are associated with which other windows.

t004024 said "From the above it obviously looks like the CWnd pointer passed is not a window???", but that's quite obviously _false_. if the CWnd pointer wasn't a window, the calls being made would fail as soon as they referenced their 'this' pointer--in other words, as soon as they referenced that invalid, non-CWnd pointer. That's not happening.

According to your notes, it's CMapPtrToPtr::GetValueAt() that's failing. That _doesn't_ mean that the association doesn't exist (if it did, the function would just return FALSE). Depending on the exact line and nature of the exception (which you still haven't told us), the problem problably means that the data in the map itself has become corrupt. That is, the map structure itself has gone bad, rather than the data in the map.

If that's true, then the most likely cause is your application deleting or destroying a temporary CWnd object somplace along its lifetime. Or, if your application is running in a multithreaded environment, there's a teensy outside chance that you're causing some race condition in the map structure.

Then again, it might not be true: we don't know exactly how GetValueAt() is causing a fault.

.B ekiM

From your call stack, it looks like MFC40 is being loaded safely, but that's a complete guess. (Since MFC40 calls into the system, then the system calls into MFC42, you should be safe. But how can I guarantee that's happening _all_ the time? There's no way for me to know that you're not asking MFC42 to manage MFC40 memory and objects, or vice-versa: that information isn't in the call stack.)

If you're writing a Netscape plugin, it's possible that Netscape itself is loading MFC40.DLL.  (But don't plugins load as DLLs? I've never written one, so I don't know.)

.B ekiM

Yes, plugins do load as dlls. The only thing I can think of as to why MFC40 is loading is that netscape uses it. Netscape itself creates a window within it's client area for you to subclass as your main window for your plugin. So the only thing I can think of is that somehow the CWnd object I've subclassed that window with isn't set up properly. (hWnd fouled up, or something along those lines.) But I've stepped through the code and noted what the handle of that window is, and it's not the one passing that message. The other point is that I only get this Access Violation when creating that "floating" window. Something which is not quite normal for a plugin to do anyway..... But in any event, none of the handles (floater window, window in netscape's client area) are the ones causing the fault. What you said about the map being corrupt, well, all I can tell you is exactly the line and variables where I get the Access Violation. That's here:

if (m_pHashTable == NULL)

the first line of the function.
I just discovered another interesting piece of information. If I comment out my display window located inside of the "floating" CFrameWnd, (i.e. it's not created.) then the crash doesn't happen. That display window is just a window derived from CWnd. Well at least I have it narrowed down somewhat.

Thank you for your help up to this point, Mike. You've already helped a lot. If you come up with any other ideas, let me know.
Thanks again.

Correction - that display window is derived from a CFrameWnd. (It exists as part of the client area of a larger CFrameWnd which is the "floater" window.)

This is very confusing. Now it's happening at
for (pAssoc = m_pHashTable[nHash]; pAssoc != NULL; pAssoc = pAssoc->pNext)
Hmph!

Mike B.
Maybe I was confused.  I think maybe it was dynamicly allocated memory was being zeroed in debug and not in release.  Now I am unsure.  I know I had some torturous bug that was caused by assuming that a variable was initialized to something when it wasn't.  Thanks for the correction.

Mike B.
Maybe I was confused.  I think maybe it was dynamicly allocated memory was being zeroed in debug and not in release.  Now I am unsure.  I know I had some torturous bug that was caused by assuming that a variable was initialized to something when it wasn't.  

Thanks for the correction.

Mike B.
Maybe I was confused.  I think maybe it was dynamicly allocated memory was being zeroed in debug and not in release.  Now I am unsure.  I know I had some torturous bug that was caused by assuming that a variable was initialized to something when it wasn't.  

Thanks for the correction.

As far as I thought, I thought U'r HashTable was a mapping of Window pointers.. and maybe U are getting the mapping of there windows and performing the operations on them.. No if this is the case, have U mapped any windows with calls to GetWindow after creating the window... Since GetWindow returns temporary pointers which cannot be stored and reused, it might be possible, that they remained valid in debug mode and hence did not crash, but in the release mode, they are accessed after they have become invalid??? Just a suggesion.

FWIW, danny_pav, I believe that memory allocated by DEBUG_NEW adds guard bytes to the beginning and end of blocks of memory that it allocates.  That is how it detects buffer under/overruns.

-=- James.

We wrestled with this one for a while, too.

Are you mixing debug flavors of MFC?  Use PView or the trace output to check to see if MFC40.DLL AND MFC40D.DLL are loaded by your program.  If they are, you have your problem.

This usually occurs by compiling the main exe for release and having a DLL built for debug.

t004024 - YOU HAVE THE ANSWER! Well, kind of. For some reason, this line is causing
my problems:

GetParent()->SendMessage(ID_ENABLE_ENHANCE);

ID_ENABLE_ENHANCE is a message I added to the message map of the parent window of this window. For some reason, executing this line of code, I get the Access Violation I explained above. Does anybody have any reason why? Am I doing something wrong?
Thanks.

TXTX is laughing hysterically!

Beatachon,
Do yourself a favor and stop mixing debug and release versions of MFC.

Good luck.

Why do I think the next post will be about a bug in MFC!?!?!?

t004024 had the answer, I meant, not you, TXTX. For some reason that SendMessage command is causing problems...but I blame it on the GetParent()-> way I am getting a pointer to the parent. Sorry.
-Ben

PMFJI,

Has anyone ever told you that calling a function that returns a pointer and then using that pointer (without checking it first) to call another function is incredibly bad form and just asking for GPFs?

Just my .02
Tom

Yes, actually, someone named tma said that once........

Yes, you're right.And guess what? I've changed the code since then to do just that. But that orirginal problem still exists.

Oh, I wasn't implying that that my comment would in and of itself resolve the problems you are having. Otherwise, I would have entered it as an answer ;)

My point was that using pointers without checking them is a recipe for disaster because they generally lead to GPFs (usually only after the application is installed at the customer site).

Whereas if you check the pointer first, you can at least give the user a message to the effect that the system is hosed and end the application gracefully.

Tom

Ben said:

"t004024 had the answer, I meant, not you, TXTX. For some reason that SendMessage command is causing problems...but I blame it on the GetParent()-> way I am getting a pointer to the parent. Sorry. "

I knew that, my point is these ARE THE EXACT SYMPTOMS THAT WE CHASED ABOUT A YEAR AGO!!!!!!!!

Many people on the team followed simialar logic, YOU ARE WASTING YOUR TIME TRYING TO FIND THE PROBLEMS THIS WAY!

(I bet if you trace into GetParent, you find some data structure in MFC that doesn't make sense!)

Hmmm. Welp, I've checked the linker /verbose:lib output and it seems I have all of the correct libraries. (don't I? (See Above.)) I fixed the problem by removing that Sendmessage call and replacing it with a simple GetParent() and then casting that pointer to the parent type and calling the function directly. Not the way I'd like to do it, but at this point I don't see any other alternative. Thanks for the help. Everyone. Now if somebody would just "answer" the question then I'll give the points. I think t30...bla.... should get the points because he's the one that made me look at GetParent().

THIS IS ABSOLUTELY THE LAST POST ON THIS THREAD.

Sure the libraries that you include may be fine.  The Libraries in the other executable units may be fine.  The interaction of the executable units that use MFC is the problem!

You can't mix the release version of MFC with the debug version of MFC.

If you do it the way you suggest, you will be finding 'problems' like this for a long time...

TXTX

Beatachon,

I understand that like the rest of us, you have deadlines to meet. However, I think that now might be a good time to remind you of a programmer's expression that you may have heard before..

"Problems that go away by themselves, come back by themselves."

IOW, as TXTX said, until you find the true cause of this problem, you are going to continue having problems of this nature (and usually at the most inopportune times)

Tom

AHHHH! This page takes WAY too long to load. I think we should put an end to this thread, as TXTX suggested. Yes, I agree with you, that I should locate the problem. I'm not under any huge deadline right now either. This actually takes priority to anything else in my head. But as of this point, I have no ideas left as to what is causing the problem. No where to go, you know?
Thanks all.

Debug.  How many times do I have to say it?

You've incorrectly coded your app: I doubt you've incorrectly built it, as TXTX suggests without any evidence or structure for his conclusion. You have a bug.  Maybe it's in MFC, but it's probably in your app.

Create a new build variant based on the release build you're doing. Add symbols to that build type.  And debug.

.B ekiM

Mike,

Have you ever tried mixing the debug and release versions of MFC within a large multi DLL project?  I causes really strange, hard to debug problems.  My only evidence is that I've been there, and this is what happens.  Besides, although it may be a bit of a shotgun approach, it is so easy to try!

At least it seems we agree on how maddening it is to repeat answers that fall on deaf ears.

TXTX.

P.S.  I like your work. (and beer.)

Oh, great guys, gang up on me. Anyway, thanks to all, and just somebody answer the question so I can dump these points.
Later.

If you're mixing debug and release versions of MFC, you'll get unhandled exceptions. Sure, TXTX, that's one of the things that can happen. But there's (literally!) hundreds of other causes for unhandled exceptions that can be categorized. And most of those other causes are more likely than a bad build.

.B ekiM

I answered the question two weeks ago, Beatachon, and that answer was rejected. You've asked a very inspecific question, and have reported weak and dynamic symptoms.

Adding symbols to the release build and debugging the problem is the only reasonable way to detect the actual cause. For some reason, you've decided that logic doesn't apply to you, despite my walking you through it carefully and more than once.

.B ekiM

Mike, could you just drop it, please? It was a simple case of me just not quite understanding what you were saying at first. If you don't want to answer the question - then fine, don't. But I like this place. I think it's nice for sharing common problems and getting answers from other people in our field. There's no reason to become hostile. None at all. If you don't like me, fine. Don't answer my questions. But don't belittle me or anyone
else on this site, please.
Thanks.

P.S. I DID THAT! I thought I told you. If I didn't, I do apologize.

It's a two way street: if you're not interested in answers, don't ask questions.

B ekiM

Touche, my friend, touche. No hard feelings, yeah? Now can we PLEASE stop posting to this thread!!!!!!!!

Well my friends. MS stink and until proven elsewise, it's there fault ( it usualy is - from expirience ).
RELEASE DOES NOT always WORK.