MFC "The parameter is incorrect"

I know that this issue is fairly common, but it's also fairly vague. I'm having one heck of a time tracking it down, so I was hoping somebody who has seen it before would be able to help. My issue is this:

I have a certain child window that causes these popups. It causes them every time when I first start the program. Then after I open about 10 of the child windows, it stops happening. But the first 10 times I open that window, I get a dialog that says "The parameter is correct". Here are the exact symptoms I'm experiencing:

- I get 3 messages when I first open the window.
- I get more messages ("random" number) whenever I hover over one of the controls on the window (1 CComboBox, 2 CDateTimeCtls and 1 CMFCButton)
- If I don't hover over one of the controller, I won't get any more messages.
- I get 3 messages when closing the window.
- After opening enough of the child windows, it stops happening.
- The error is disrupting program flow, because my window doesn't load completely when it happens.
- Pausing on the message box shows the call stack somewhere in mfc.dll
- No exceptions are thrown.
- The error doesn't happen when running from withing VS. I have to build the application and run it separately. (But it does happen if I run it separately and then attach the VS debugger).

As background info: I'm building an MFC application in Visual Studio 2008 on Windows 7.

From what I can tell, it has to do with one of the MFC controls I'm using, I just can't seem to find which one. Commenting out the controls I see doesn't do anything. It almost seems like a resource error, but everything I read online points to it being an MFC issue.

Any help is much appreciated. Hopefully I've explained it properly.

It is virtually impossible to resolve your problem without analyzing your code and debugging.
Could you please attach your project in a compressed form? Do not include debug/release folders.

I agree with JohnCz.

However:

Quote:

---

Originally Posted by Access_Denied

- The error doesn't happen when running from withing VS. I have to build the application and run it separately. (But it does happen if I run it separately and then attach the VS debugger).

---

Do you use some file names without the paths?

I'm afraid posting the project wouldn't be possible. Even if I got the OK from my boss to post the code, it takes a few hours to get it all configured to run properly in Visual Studio. Obviously that's a bit much to ask from anybody, so I understand if you can't help at all. I was really just hoping for a miracle I guess. :/

As for the paths, no, I don't use any absolute paths in the program or anything like that. All paths are either relative (our files) or gotten from Windows (such as temporary files folder).

I do have one question that might be related. In version 5 of our software, we distributed our EXE with mfc80.dll and the manifest files (along with the others). But in version 6 we moved from InstallShield to a VS Deployment Project which doesn't include any of those files. I'm assuming that it uses a shared DLL in the Windows folder. Could this possibly be a source of error? Could different versions of MFC be causing this issue? I read a page yesterday (http://go4answers.webhost4life.com/E...id-210535.aspx) saying that VC6 didn't have a problem with some parameters but VS2010 did. Is there a way to include the necessary DLLs in the installer as to avoid version issues?

Quote:

---

Originally Posted by Access_Denied

IObviously that's a bit much to ask from anybody, so I understand if you can't help at all. I was really just hoping for a miracle I guess. :/

---

Since you have the debugger attached to the program, and you can duplicate the message box, try this:

When the message box appears (assuming you've attached to the application), do a "Break All" and see what the call stack is. Then you can see which function and parameters are causing the issue.

Regards,

Paul McKenzie

Sorry, I didn't make that entirely clear. (I was also a bit wrong anyway.) Break All just puts me in a call stack with all library calls. (The actual error box is in user32.dll.) But there are no calls to any of my functions and there are no calls which contain source code. The only thing I can do is view the assembly code.

The threads call stacks should be analyzed not only at their top. But if you go down the stack and anyway cannot see any of your functions, man, you're in trouble, and nobody here could give you a simple advice that would solve all of your problems at once.

Just live with that: debugging is a skill that you should develop yourself. Debugging includes not only inspecting variable values and going call stack up and down. First of all it implies that you understand how your code works, you understand overall architecture and design, you understand basic OS principles. Of course, except trivial cases. BTW, "understand" here implies being able to model the situation in your mind. And only when you made some theory, you can play with your code to get some confirmations, direct or indirect.

As for sending your code here. Nobody asks you to send your real code. One of the implications of the request is to see if you're able to reproduce your problem in a concise manner. A little project is the only way for others to see your problem and provide a real help. But nobody would dig into your tons of real code for free.

If you cannot reproduce your problem, and cannot solve it in your real project, you should discuss this with your boss. The sooner you do that, the better chances for the whole project are. A more experienced developer can find and fix a problem in acceptable time, which problem a beginner never could fix.