I have a winforms app (>75k lines of source code), I have just added some new functionality and a new form and I'm getting the 'can't create window handle' error but only when running inside VS. The app builds OK and when i run it as the executable it is using 597 handles, 94 GDI and 83 USER and the new form works just fine apart from my logic errors in it. So as far as I can tell; my app is well below the 10,000 limit where things start to break therefore the problem is in/with VS somewhere but I may have hold of entirely the wrong end of the stick or possibly completely the wrong stick.
I have cleaned, rebuilt, rebooted etc and it stills falls over.
I'm using Process Explorer (thats where the previous numbers came from) but can't seem to find VS in there to check what its total handle count is.
VS2017 on Win 11.
Yes, I have googled it and explored things to look at but I can't find a result that matches 'Studio falling over but the exe running fine', any help / pointers very much appreciated as I obviously can't debug the new form which does make things somewhat difficult.
The underlying issue was to do with a pop-up form being generated by the parent form during its load processes, I found that the parent hadn't been issued a handle before it was trying to show the pop-up. Before you ask... I'm capturing data from a network sensor via the pop-up, which, once the user has accepted the incoming value, feeds the data back to the parent form. I assume that in run-time everything runs faster and it doesn't hit that 'un-coupled' point. Changed the code in the instantiate/load/shown cycle it runs and all is well.
Thanks once again Hans, headache solved.
Related
I made a program, which works fine on my PC without any errors, it also works fine on some office PCs, but it crashes without any describable error on customer's PC and some others.
Crashes are completely random, sometime it may crash and sometimes not.
Crashes are not related with any actions, sometimes it may crash when they just look at the program and wait for crash.
Customers send me this beautiful screens and want me to solve this.
There you see common error reporting dialog, but not info about Exception.
My program uses Unity Web Player running in WebBrowser control. It's always run in background on the hidden tab which becomes visible when needed.
Any ideas how to handle such errors?
I think you should first ensure that the environment at your place and that of your customers are identical.
Maybe there're dll or other programs installed at your place (Unity web player as you mentioned for example) or anything in your Registry that may differ.
Else there's no point in getting error on one PC and not on another.
Make sure all dll are well deployed
Check your registry,
Ensure that all related programs are well installed
I've got a problem that's driving me nuts. We have a C# project that has a few types of custom controls, but has several hundred instances of those controls (don't ask). Every time I do anything that requires compile I get the following behavior:
The project appears to build very quickly (like 3 or 4 seconds).
Then VS becomes totally unresponsive for quite a while (maybe 15 seconds to a minute)
The status at the bottom of the window shows "Build Succeeded" during the unresponsive period.
Clicking just about anything will cause a spinner to appear.
Eventually the spinner will go away and the status will show "Ready" at the bottom, at which point I'm back in business.
I'm almost certain that this is a self-inflicted problem, but for the life of me I can't figure out what is going on during the "spinning" period. Is there any way to see what's going on during the build process so that I can determine precisely how I'm shooting myself in the foot?
UPDATE: I tried a strange experiment. I created a new application using the exact same user controls and then just plopped down about 2,000 of them on my form. No problem at all, this application works fine. How incredibly odd...
Close the form design view before compiling the project.
If that did not work (which worked for me but not for you as you've mentioned in your comment) then I think it's something about your custom control like trying to connect to a server and validating it's licensing. Check your internet traffic with something like Wireshark. I hope that helps.
I have a Silverlight project that we use internally that I wrote - and since we've not had any need to work on it, it's been a while since I've opened the project. I opened it up this morning and everything is fine in terms of building, but whenever I try to debug I get the following error:
Unable to start program "http://mymachinename/mywebsite/index.aspx"
Of course, running it in Firefox works fine but no symbols are loaded. Running without debugging still throws the same error but IE loads up anyway...
Navigating to the website in IE works fine - SL app opens up, loads data etc etc, all looks good
I've Googled this all morning (usually quite good at finding info) and been through all the questions on SO and I can't figure out what's going on - there doesn't seem to be any messages in the event log, there are no messages in any VS output window, the w3wp just terminates immediately after starting (probably due to there being an error trying to open IE). I've tried reinstalling IE, cleaning/rebuilding, using local dev server, creating a new web project, turning on/off settings in IE9 etc etc
Nothing seems to make a difference - anyone got any experiences of this and has fixed it without doing one of the things I've already done? Any other suggestions?
Thanks in advance!
UPDATE
Just to be clear in case anyone asks - I get this problem when creating a new web project - i.e. everything I said I'd tried (above) didn't change the behaviour. It showed the same error no matter what I'd done so far (that includes a NON SL web project)
I've also tried attaching the debugger to w3wp that is running (the standard IIS process) and I can't seem to get it to debug (no symbols are loading), but that might be another issue altogether. I'm going to look at that next and maybe if I figure that out it might lead to fixing this issue
UPDATE 2
Debugging in Firefox works - I attached to w3wp with no success, then realising my stupidity (SL being a client side app!) I attached to the plugin-container.exe that FF runs its plugins in. This works. I can probably do the same for IE and just attach to IE, but why won't it start up from VS?! hair pull
UPDATE 3
Just in case anyone asks, the default browser is set to IE in VS. Also I've managed to debug by attaching to IE, it just won't start IE from within VS - annoying but I can live with it for now. If anyone does have a suggestion though, feel free...
For anyone's information in case they have this same problem, it ended up being that the port I was running my site on was also running a SharePoint site!
I created a new site on port 81 and used that for dev - not sure what setting on the other site caused the issue but it ended up working on port 81.
I've never seen this issue before, and I'm not even sure if I'm posting in the correct place.
My Co-worker wrote a C# program (windows), that includes a web control. In that web control are a bunch of iFrames. Now, when the web control is populated (max 15 records), everything is fine. 99% system idle process. But once you minimize the program, boom, 99% process goes to the c# program and stays there!
If the web control is not populated. There is no issue with minimizing and maximizing the program.
There are no functions that run when the program is minimized or maximized, so there's nothing to debug...
The program is crashing on two computers, but on the rest (about 8 computers) it runs fine.
The two computers that "crash", are not very similar... so it's proving hard to find what may be causing the issue. One computer is xp, the other is windows 7, one is ie7, the other is ie8.
If anyone could point me in the right direction, or if anyone had a similar situation and has a solution, I'm all ear's and eye's!
I would attach Visual Studio to the "99% CPU" process, break all, and see what's going on in there. That's first step.
Doesn't Windows write inactive (i.e. minimised) application state to disk, to free up resources for active (non-minimised) windows?
One of the hooks / events called when you minimise the application could be causing IO hangs. You should get a diagnostics tool like Sysinternals Procmon to see if IO (or any other process) is hanging based on the minimise event.
Good luck!
Chris.
So my co-worker didn't find the thorough answer as to why it was crashing, but it was crashing due to the .net Web control. He swapped out the control for a VB6 control and it now works.
I was wondering if there was a way to completely lock my code while debugging it within Visual Studio 2008. The code documents lock automatically when running as 64 bit applications, which I greatly prefer; however, I do most of my coding making add-ins for Excel, which is 32 bit. The result is that even though I target 'AnyCPU', the VS host knows that it is running within a 32 bit process and, therefore, the source code is not locked while the code is running hosted in Visual Studio.
I can turn off Edit and Continue by going to Tools > Options > Debugging > Edit and Continue, and then unchecking the 'Enabled Edit and Continue' check box. This does not completely lock the code, however. This does prevent any edits in the code from being executed in the current run, but it does not prevent mouse clicks or keystrokes from actually changing the code.
Again, when working with 64 bit applications this does not occur -- the code is completely locked. I greatly prefer the code to be completely locked for at least a couple of reasons:
I can accidentally hit a key or the like while debugging, which I definitely do not want to do. It's rare, but it is an issue.
Many of my automated tests drive the user interface via SendKeys. When stepping through such a test using the debugger, however, I can sometimes forget that some of the aspects involve SendKeys, which means that keystrokes wind up getting sent to the Visual Studio IDE instead of Excel.
In issue #2, above, the unit test fails, which is fine -- my bad -- but having all the keystrokes sent to the code module and destroying my code is completely unacceptable.
Does anyone have any ideas here? Can one completely lock the code when running hosted in Visual Studio while compiled against a 32 bit CPU?
Some related posts on this issue, but none of which directly address this:
How to: Enable and Disable Edit and Continue
“Changes to 64-bit applications are not allowed” when debugging in Visual Studio 2008
How do I enable file editing in Visual Studio’s debug mode?
How does “Edit and continue” work in Visual Studio?
Can we edit our code while running the application
Editing C# while debugging
Thanks in advance for any help or ideas...
Mike
Here is a trick I use under Visual Studio 2005 (don't have a chance to test under Visual Studio 2008, but it should work):
Open the executable assembly's properties
Go to the Debug tab
Check the Enable unmanaged code debugging checkbox
The code documents should stay locked, even when a breakpoint is hit, and any attempt to change it should trigger a popup saying "Changes are not allowed when unmanaged debugging is enabled".
Hey there - sorry I can't help you with completely locking your code - I have the opposite desire: to completely UNLOCK it during debug, but I can help you with your second issue.
I suggest that you consider checking the active window before sending any keys and if the active window is other than your target site, pause the execution of your test until focus is returned that that window.
I know it's not the solution you want, but it probably wouldn't hurt to prevent other similar issues.
Best of luck!
Adam
Here is the best I could come up with. It works, but there are some steps you may not want to take.
Essentially, the technique is to set the files of your project to Read-Only when you run the application, and then set them back to writable once your application ends.
However, in VS2k8, by default, setting a file to Read-Only still allows you to edit the file. You need to first turn off the setting "Allow editing of read-only files..." in Tools > Options > Environment > Documents.
Second, you need to add the following key to the registry as a DWORD and set its value to 1:
HKCU\Sofware\Microsoft\Visual Studio\9.0\Source Control\UncontrolledInMemoryEditDialogSuppressed
This still won't work completely. What you then have to do is set your Source Control for that project to Visual Source Safe. (<-- this is the step I'm assuming you won't like.)
Then restart VS2k8.
At this point if you set one of your files to read-only, you will see that Visual Studio will not let you edit this file at all. When you try, it plays your computer's exception music.
Now, to make your files read-only when you run the app, set a post-build process to do this. That's easy.
Harder, is to set them back to writable once your app finishes running. The simplest solution is probably a batch file shortcut.