When I deploy my app on other machines, this error comes up:
Now if I uninstall my app and re-install it, the error message does not come up. Has anyone else encountered this? I cant make sense of the stack trace either.
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
When I deploy my app on other machines, this error comes up:
Now if I uninstall my app and re-install it, the error message does not come up. Has anyone else encountered this? I cant make sense of the stack trace either.
The diagnostic indicates that the native CreateWindowEx() API function failed. There are very few reasons for it to fail, the most common one is a gross mistake in the window procedure for the window. That certainly is not the case for the Form class, I’ve only ever seen Windows Forms programs fail with this error because the process exceeded its handle quota.
To explain that is going to require some hand waving. First off, by default a Windows process is only allowed to create 10,000 handles, GDI objects and user32 objects. It is of course very unlikely that your program consumed that many right at start up. Seeing this happen when it is started by the installer is however a lead. Msi.exe gets special dispensation, it is allowed to create many more handles. I’ve seen it do this, the VS2008 service pack 1 installer I ran on an old unpatched version of XP got up to 500,000 handles about 2 hours after I started it before it decided a reboot was necessary to complete the install.
Your installer would use CreateProcess() to start the program. It has an argument named bInheritHandles that determines whether or not the child process inherits the handles of the parent process. A possible scenario is thus that the installer consumes many handles, and that it has the bInheritHandles argument set to TRUE. Your WF program would then start with its handle quota already exceeded, creating another handle will fail. The SetVisibleCore() method is indeed the one that creates the main form’s Handle property.
This is all conjecture of course, you should be able to see this for yourself with Taskmgr.exe, Process tab while the process is displaying the exception dialog. Use View + Select Columns and tick Handles, GDI Object and USER objects. An ultimate fix is going to require finding out why the installer is consuming so many handles. Or using a different way to start the program.