Some days ago our new Visual Studio 2013 copy was sent to us.
I was working with 2010 before, and after working with 2013 for a couple of days, I really like it, but now I've found something really annoying. Have a look:
Well, my Visual Studio is in german language, but I think you can get what is happening.
What I am wondering is why VS says I've got an unhandled exception. What other than putting a try catch around this I can do to handle the exception?
This is just an example. My real code is a bit more complex, and the try/catch is located some levels above this piece of code.
I can not remember VS2010 behaving like this.
I had a look in the exceptions settings, but I did not change anything there, so I'm using default settings:
What I am wondering is why VS deals with this code as if it were unhandled, when as you can see it is not. That's why I do not want to change anything in my exceptions settings. Do you have any ideas or suggestions?
It's helping you. At runtime you would get the expected result ie. it will go to the catch block.
Disable all exceptions in the options and VS will ignore all your exceptions and let the code catch them.
EDIT :
You should expand the lists as they will contain checked items even if the parent/group checkbox is unchecked.
so i tried Alex his hint, to uncheck the Exception in the dialog.
After unchecking the Exception my code acted like it runs outside the VS debugger.
But i was not happy with the statement
The setting is 'global'. It will ignore the exception from then onwards
So I went on with some researches.
I put some unhandled IOException throwing in my code. VS broke at the line of throwing the exception, what i was wondering about, because i unchecked the said point. Watching VS dialogs i figured out that they were not completly the same, they have a smal difference.
One said (as my VS is in german i transalted it to english by myself, maybe the text is quite a bit different in real): IOException was not handled - this is the unhandled IOException after unchecking the item at the Exception dialog.
The other said (translated by myself again): IOException was not handled by usercode - this while the item is checked in Exception-dialog.
So what is the difference between code and usercode?
I went to google for some research, i found two very importand sites. First explains the meaning of the ExceptionDialog. I do not quote anything, because all informations on this site are notable.
ExceptionDialog explained
Now let us know how VS is detecting usercode. Therefore i found the secound site:
usercode
With all these informations i did these experiments:
Delte .pdb file of the dll containing activateCommunication() -> VS did not break
Put pdb back again, unchecked "Enable the Visual Studio hosting process" -> VS did not break
Well, it is a bit more clear now. What i am still wondering is why with hosting process enabled, VS breaks, even if i have handling code. Maybe there is some debugCode around calling my method that might be seen as the "system code" mentioned on website one!?!?
Well, thats what i found out.
Greetings
Ronny
Related
While I am creating an ASP.NET MVC view in Visual Studio 2019, I am getting this error:
There was an error running the selected code generator: 'the value -1 is outside the acceptable range 0,2147483647
How can I solve it?
We have to open vs-2019 and select tool -> Options-> General -> ignore GPU memory access exception if the data written didn't change. Mark it as checked then error will be disappear.
I ran into the same problem tomorrow, tried many manipulations found on different subjects, including yours, nothing worked. Finally, someone gave me a "solution" that let me continue my project, hence I'm sharing it here in case yours doesn't fit someone's issue: simply copy/paste any view...!
Yeah, it doesn't make the resilient error go away, and you'll have to hand code each new view, but at least you'll be able to keep coding your project.
Hope this helps.
You might want to check out my answer to this in:
the value -1 is outside the acceptable range of [0,2147483647]. Parameter name: value
I have "trace" on but do not get a "stack trace" for this error in my Asp.Net development project. On other errors I have seen stack traces, but my question is why don't I see one now?
This is about a DevExpress gridview. Could it be that DevExpress errors are handled differently from plain Asp.Net code?
I have set breakpoints on all sorts of interesting places but no avail. Perhaps there are errors that are not associated with stack traces?
I tried with Firefox and IE browsers.
Kind of stuck, hope this to be a silly problem.
From: ASPxGridView - Object reference not set to an instance of an object
This issue is caused by the fact that some object reference equals "null". I suggest that you determine the problematic reference in the following manner:
Disable ASPxGridView's callbacks by setting the ASPxGridView.EnableCallBacks property to "false";
Perform the required steps to reproduce the issue.
You will receive the Server Error screen with information about the exception that has been thrown (and the problematic reference/code line).
If this does not help, please provide us with a sample working project (containing only the problematic ASPxGridView bound to any portable datasource) that illustrates the issue, so that we can examine it on our side under the same conditions.
Also, the exception you see is raised in server code and to be able to
catch it, please adjust the VS as shown below:
Go to the Debug-->Exceptions dialog and check the Common Language Runtime Exceptions and check the check box in the Thrown column;
Go to the Tools-->Options-->Debugging and uncheck the Enable Just My Code (Managed Only) check box.
After doing these all stuff, you are not able to get the error then provide your markup to check what is actual problem..
In case you're using Visual Studio, have you checked Debug -> Exceptions -> Common Language Runtime Exceptions checkbox ?
you may use try catch block in your code to get the location where the code is breaking else set the Common Language runtime thrown to true in exception window(to open this window press ALT +CTRL+E)
Hi i have break on unhandled exceptions turned on, and turn off the ones i expect to happen as part of my code.
But every so often (usually on restarts visual studio resets all my Debug->Exceptions to all unselected
I want to backup these values, or manually copy the file so i can put it back rather than having to go through and reselect the ones i want.
Does anyone know how to do this?
I have tried to find answers on stack overflow already, and cannot find any, i have search google and also come up empty, i am really stuck
The way i have got round this is by upgrading to VS2010 or VS2012, as the export settings saves the exceptions list, which vs2008 didn't seem to do that.
I apologize in advance if this is really a Super User question... I just wasn't sure, but this seems more on the dev. side than on the tech support side. :)
This isn't necessarily a problem, but it does actually drive me totally bonkers on my system. It also only happens on my computer.
When I launch any application, even a blank WPF application, I see four exceptions:
A first chance exception of type 'System.IO.DirectoryNotFoundException' occurred in PresentationCore.dll
A first chance exception of type 'System.ArgumentException' occurred in mscorlib.dll
A first chance exception of type 'System.ArgumentException' occurred in mscorlib.dll
A first chance exception of type 'System.InvalidOperationException' occurred in PresentationCore.dll
To figure out where these are coming from, I then set VS2008 to break on any thrown CLR exceptions, and here is the information:
Exception #1:
Cannot find a part of the path 'D:\Dell\Reader2.0\SPLASH.SYS\fonts\AscenderUni.ttf'.
Exception #2:
Culture name 'ug' is not supported.
Parameter name: name
Exception #3:
Culture name 'ug' is not supported.
Parameter name: name
Exception #4:
There is no registered CultureInfo with the IetfLanguageTag 'ug'.
I've poked through Process Monitor and Process Explorer. Process Monitor shows that my application is doing a RegQueryValue, which I'm certainly not responsible for... but some DLL (presumably from Dell crapware) is getting loaded by my process and is reading this regkey. I then looked at Process Explorer, hoping to see which DLLs my application is loading, but can't find that info. I then tried PrcView and saw the modules my application was loading.
I was surprised to see how many other modules were getting loaded, but I didn't see anything Dell related. I'm also wondering how it is possible that a Norton Internet Security DLL got loaded into my process, but I assume that's intended and something special that Norton does to ensure that a process is safe to execute.
What else can I do to identify and remove where these exceptions are coming from?
UPDATE
Not sure if it's confusing what I'm getting at here. This exception is raised in a DLL that my application loads for some reason (I don't reference anything Dell-related from my project). I've now uninstalled that app, and I still get the stupid exceptions. It's all technically fine because the exception is handled somewhere, presumably within that DLL, but I'm just annoyed because four extra messages (actually 8, since I have to close two dialogs per exception) pop up when I run my application. Call me lazy, but I never asked this damn DLL to load in the first place. :)
Perhaps now it's time to use msconfig to start disabling some Dell services. I'll play with that later when I actually have free time.
No file corruption. As I've been trying to hunt this one down for a while, I figured out what happened. Somewhere along the way, a font was installed with Uighur culture, which is, apparently a Turkish/Chinese culture (as best as I can tell), and their CultureInfo tag? "ug". When the fonts were cached, the system was attempting to load the Uighur culture. Sadly, my installation of Windows seems to be conspicuously missing this culture in Windows. Knowing that I won't be using the culture on my machine anytime soon, I followed the directions on MSDN to create and install a new culture.
Though the error won't hurt anything major. It is just a first chance exception, after all, it was annoying the crap out of me. So here's what I did.
Create a new console app.
Add a reference to sysglobal.
Add the following code:
var culture = new CultureAndRegionInfoBuilder("ug", CultureAndRegionModifiers.None);
var ci = new CultureInfo("en-US");
var ri = new RegionInfo("US");
culture.LoadDataFromCultureInfo(ci);
culture.LoadDataFromRegionInfo(ri);
culture.Register();
Build.
From Windows Explorer (you need admin privileges to do this), run the compiled executable as administrator.
If all goes well, there should now be a file in C:\windows\Globalization called "ug.nlp".
You shouldn't receive that message again.
I had the same problem.
It disappear after I did:
Clear the WPF font cache and restarted Visual Studio.
Clear the cache: http://support.microsoft.com/kb/937135
Éric
It is very unlikely to be the shovel-ware on your machine. These DLLs need to inject themselves also into non-managed programs, they have to be written in a language that doesn't depend on the CLR, like C or C++. And accordingly cannot generate managed exceptions.
These exceptions look like machine configuration problems to me. Junk in your registry. The bad culture name (sounds like "us" got corrupted to "ug") generates three of them, the font is probably listed in the registry but missing from the disk.
Short from a OS reinstall, you could possibly diagnose this by using both ProcMon and the debugger. Use Debug + Exceptions, Thrown checkbox to force the debugger to stop on the first-chance exception. When it hits, switch to ProcMon, the registry key or file should be visible very near the end of the trace.
With leads from the above answers I was able to solve this issue by deleting the font "Microsoft Uighur Regular"
First chance exceptions are normal - these are displayed whenever an exception is thrown, whether it was handled or not. They exist so you can go into your code and find out why they are thrown.
However, if the exception has been handled, there is no problem and execution will resume.
If the exception was not handled, a second chance exception will be caught by the debugger and execution will halt.
This is normal and shouldn't be of concern. You can always hide them - see this question and answers for more details.
In regards to the actual exceptions - there is some code (third party or your own) that is trying to access a ttf in the mentioned directory, this cannot be found, hence the exception (which was handled, so no problem).
The other exceptions are due to create a non existing CultureInfo (ug) - perhaps this is supposed to be uk? Check configuration and code for this.
These values may be configured in the registry.
I am using this - otherwise excellent - vb tab control in one of my c# apps. When the app using it is installed on another machine, Windows tells the user in its usual friendly and descriptive manner that "The application encountered a problem and needs to close". I guess the control has some hidden vb-related dependency, but what can that be?
Any ideas guys?
Since the tab control appears to be managed code as well, your 'crash' is most likely an unhandled .NET exception.
Looking at the error details (by expanding the error dialog using the button provided for that purpose...) should give you the exception message, which should give you an idea of what's going on. If it's a missing dependency DLL, the name should be included in the message.
To get the full exception, including the stack trace, one of the following should work:
Least effort: in the first line of your own managed code, add an unhandled exception handler which shows the full exception in a message box or logs it to a file prior to rethrowing it
Medium effort: attach a debugger to the process on the client machine. If it's on your local network, setting up remote debugging should be trivial, and should also allow you to debug exceptions that occur prior to your first line of code executing (which may very well be the case if the error is binding-related...)
Most effort: obtain the crash dump file from the client machine, and look at the managed exception using Windbg and the SOS debugging extensions. Getting productive with the tools involved will take some time, but on the plus side will teach you valuable debug ninja skills that will allow you to tackle pretty much any 'mysterious crash'...
BTW, all standard 'VB dependencies' are part of the default .NET Framework install, so that's not your problem -- only the exact exception (and possibly stack trace) will tell you what's going on.
Click the 'What data does this error report contain?' button and there will be more descriptive info. (i.e. type of the thrown exception, module etc.).
For additional info see Dr. Watson vs. CLR.
Is the dll containing the control distributed with your app? Perhaps you have a dependancy in the GAC thay you are missing?