private void button1_Click(object sender, EventArgs e)
{
///IDE will notify me of this exception
throw new Exception();
}
private void Form1_Load(object sender, EventArgs e)
{
//IDE will not notify me of this exception
throw new Exception();
//code will not execute
MessageBox.Show("test");
}
why?
----------------------EDITED----------------------
the correct answer is what ChrisA mentioned.
some quotes from microsoft :
This is a known bug with x64 versions
of Windows and the way exceptions are
handled. One way to work around this
issue while debugging is to go to the
Debug -> Exceptions and select
'Thrown' for for the exception types
you are interested in. This will stop
the debugger when the exception is
first hit (and before Windows eats it
up).
This bug was closed as "External"
because this behavior results from how
x64 version of Windows handle
exceptions. When a user mode exception
crosses a kernel transition, x64
versions of Windows do not allow the
exception to propagate. Therefore
attached debuggers are unaware of the
fact that an exception occured
resulting in the debugger failing to
break on the unhandled exception.
Unfortunately where is nothing that
the Visual Studo team can do to
address this, it is the result of
operating system design. All feedback
regarding this issue should be
addressed to the Windows team; however
the Windows team considers this to be
the "correct" operating system design,
and considers the x86 behavior to be
"incorrect".
This hotfix has not undergone full
testing. Therefore, it is intended
only for systems or computers that are
experiencing the exact problem that is
described in the one or more Microsoft
Knowledge Base articles that are
listed in "KB Article Numbers" field
in the table at the end of this e-mail
message. If you are not sure whether
any special compatibility or
installation issues are associated
with this hotfix, we encourage you to
wait for the next service pack
release. The service pack will include
a fully tested version of this fix. We
understand that it can be difficult to
determine whether any compatibility or
installation issues are associated
with a hotfix. If you want
confirmation that this hotfix
addresses your specific problem, or if
you want to confirm whether any
special compatibility or installation
issues are associated with this
hotfix, support professionals in
Customer Support Services can help you
with that.
Are you developing on an x64 machine?
If so, you might like to have a look at this.
That thread also refers to a very detailed explanation of the whole issue.
This, and another show stopper (for me anyway, the workarounds didn't work for me, or my colleague) on x64, resulted in a rebuild of my dev box with win7 x86.
The problems have all gone away now. But it's very disappointing.
Related
My company finally upgraded our development team from Windows XP to Windows 7 64-bit computers and I just discovered an odd error with existing code in the new environment. The project in question references a COM library that's used to interact with our document image management system. Any attempt to initialize an instance of this API's Library class is now throwing an SEHException. The error code returned has not been informative. Here is the full Exception from a stripped-down sample project I wrote to test this problem:
System.Runtime.InteropServices.SEHException was caught
ErrorCode=-2147467259
HResult=-2147467259
Message=External component has thrown an exception.
Source=FileNetTestLib
StackTrace:
at FileNetTestLib.Library.Logon() in C:\Projects\Tests\SEHException\FileNetTestLib\Library.vb:line 4
at SEHException.Form1.btnLogIn_Click(Object sender, EventArgs e) in C:\Projects\Tests\SEHException\SEHException\Form1.vb:line 7
InnerException:
While working with my sample project I was able to confirm the following:
The Exception only occurs when debugging; running without debugging does not throw any exception
The Exception DOES NOT occur when debugging on Windows XP (tried on two Win7 and two XP computers)
The Exception DOES NOT occur when we change the target framework to anything lower than .NET 4. It only occurs on .NET4 or higher.
So to summarize, the error occurs if we are debugging on Windows 7 targeting .NET4 or higher. It does not occur if we change any one of these factors.
In researching this I discovered that .NET4 changed its security model for how it handles exceptions thrown from non-managed code. It looked at first like this might relate to the issue, but from what I've managed to learn so far, the changes affect only a subset of SEHExceptions and apparently not the one I am getting because (1) I am able to catch the SEHException in a try...catch block where the change in .NET causes the affected exceptions (corrupted state exceptions) to not be caught by .NET at all unless you make certain changes to your code or config file (which I have not made and have confirmed are not present in my project) and (2) the problem is only occurring for me under Windows 7 and I haven't found anything to indicate that these changes in .NET4 were Win7-specific.
FYI, I don't have a 32-bit version of Win7 so I can't confirm if the issue is specific to Win7 64-bit or Win7 in general. I AM compiling the project as x86 since I cannot compile it as x64 due to the COM component. I have also tried this on VS 2013 as well as VS 2010 and get the same results on both.
Since the problem only occurs while debugging I checked which Exceptions I am allowing the debugger to break on (hoping it was selected and I could just uncheck it to get the debugger to ignore it) and SEHExeption is unchecked (under Debug|Exceptions). I also checked the Debugging options in VS and "Break when exceptions cross AppDomain or managed/native boundaries" is unchecked. Changing either of these has not made a difference.
I also tried initializing a completely different COM component (ImageMagick, in this case), to make sure the error wasn't occurring for ANY COM component but I did not encounter any problems with that. I am about to contact the vendor of the COM component that is causing an issue for me, but I was wondering if anyone else has encountered any similar problem with other COM components and if so if there's a way to prevent or ignore these types of errors when debugging since the error only appears to be generated as a result of running in the debugger.
I ran into a problem with using WpfApprovals on different versions of the OS. My personal laptop is running Windows 7 Enterprise and the build server is running Windows 7 professional. Since the WpfApprovals is using the OS name in the approval file name, the tests are failing on the build server.
I tried a number of options to try to avoid including the OS in the approval name, however, it looks like this behavior is hard coded in WpfApprovals.cs...
public static void Verify(Control control)
{
ApprovalResults.UniqueForOs();
ApprovalTests.Approvals.Verify(new ImageWriter(f => WpfUtils.ScreenCapture(control, f)));
}
... short of creating a modified version of the library that comments out the ApprovalResults.UniqueForOs() call, is there a way to disable including OS info in the approval file name?
While I can appreciate that these tests will fail with different major os versions, they shouldn't fail accross different editions. I noticed that the standard string verifier doesn't force the UniqueForOs style naming.
Good point.
This Wpf is a bit tricky because the consistency is always an issue, but forcing it might not be the best idea, especially with no way to override the default behavior. While we figure out the correct solution for the next version, here are a couple of workarounds for 3.0.5
1) Copy file
You can just copy the approved file over to match both OS versions. This sucks a bit but involves no coding.
2) Customized Wpf call
While you stated not doing this it is a pretty easy fix
public static void Verify(Control control)
{
ApprovalTests.Approvals.Verify(new ImageWriter(f => WpfUtils.ScreenCapture(control, f)));
}
Unfortunately this is it. There is not way to intercept the namer.
Thanks for bring this to our attention!
Many times when I change VPN status by disconnecting a remote network my VS instance immediately crashes.
This is the closest thing I can find in the event log. Anyone have any ideas about this?
Exception: System.Net.NetworkInformation.NetworkInformationException
Message: Invalid access to memory location
StackTrace: at System.Net.NetworkInformation.SystemNetworkInterface.GetAdaptersAddresses(AddressFamily family, FixedInfo fixedInfo)
at System.Net.NetworkInformation.SystemNetworkInterface.PostWin2KGetNetworkInterfaces(AddressFamily family)
at System.Net.NetworkInformation.SystemNetworkInterface.GetNetworkInterfaces(AddressFamily family)
at System.Net.NetworkInformation.SystemNetworkInterface.InternalGetIsNetworkAvailable()
at System.Net.NetworkInformation.NetworkChange.AvailabilityChangeListener.ChangedAddress(Object sender, EventArgs eventArgs)
at System.Net.NetworkInformation.NetworkChange.AddressChangeListener.AddressChangedCallback(Object stateObject, Boolean signaled)
at System.Threading._ThreadPoolWaitOrTimerCallback.PerformWaitOrTimerCallback(Object state, Boolean timedOut)
I got this exception when running my 32 bit application (which was built with /LARGEADDRESSAWARE enabled) on Windows 7 from time to time. While trying to find the problem I came across a hotfix that appears to fix the issue.
Try the following hotfix and see if that fixes it for you: http://support.microsoft.com/kb/2588507
I've integrated Flurry (http://www.flurry.com/) into my phone 7 app. The only code needed is this line in application launching
FlurryWP7SDK.Api.StartSession(ApiKeyValue);
However, as soon as that line is hit the application crashes with a KeyNotFoundException. The stack trace is included below. It appears to be querying isolated storage settings and failing when the key doesn't exist.
Does anyone have any experience with this error or even successfully integrating flurry into a Phone 7 app?
at System.ThrowHelper.ThrowKeyNotFoundException()
at System.Collections.Generic.Dictionary`2.get_Item(String key)
at System.IO.IsolatedStorage.IsolatedStorageSettings.get_Item(String key)
at A.ca98fb38190f0d5cad84c67a779d17229.c204dba68825403c905efd7bfd067b17b(String ce0360de492f1f363775feaf6d6a8ced5, Object c8d4be677f7ee63f6756e13f285072523)
at A.c3f1105d518a239d73e2236200494de25.set_cfca54db015a16ab23de44b4d5c65e9a3(String c8d4be677f7ee63f6756e13f285072523)
at FlurryWP7SDK.Api.StartSession(String apiKey)
at AppName.App.Application_Launching(Object sender, LaunchingEventArgs e)
at Microsoft.Phone.Shell.PhoneApplicationService.FireLaunching()
at Microsoft.Phone.Execution.NativeEmInterop.FireOnLaunching()
Edit
After discussions with Flurry support it appears that the KeyNotFoundException is caught by Flurry code. However if your debugger settings are to break when the exception is thrown you will break into the debugger regardless. Continuing execution will then work because the exception is caught and handled by Flurry.
I can't verify that this is the solution because I no longer have access to the dev environment that was indicating the error, but it appears to be a likely solution.
I work for Flurry. We have many successful deployments on the Windows 7 platform. You and Buju may be experiencing an emerging issue that has not come to our attention previously. Please email winmosupport#flurry.com as the diagnosis may involve discussing account specific details. Once we determine the underlying cause we can post back to this thread so the community has the benefit of our investigation. Thanks for working with Flurry.
Edit
I just wanted to follow up on Mac's comment as the KeyNotFoundException may manifest in two ways during debugging. As Mac noted we do caputure the KeyNotFoundException, however, the debugger sees the exception first before we can handle it within our library. The debugger's behavior is dictated by the setting in Debug > Exceptions.
If the checkboxes under Thrown are selected the program will be stopped and the stack trace above will be output. If the checkboxes under Thrown are not selected the output will generate an error like the following:
A first chance exception of type 'System.Collections.Generic.KeyNotFoundException' occurred in mscorlib.dll (this is the message Buju received)
The program will continue following this message as it just serves as a notice that an exception occurred somewhere within the program. More information on first chance exceptions can be found in the following articles:
What is a first chance exception - http://blogs.msdn.com/b/davidklinems/archive/2005/07/12/438061.aspx
How to handle (disable) first chance reporting - http://www.helixoft.com/blog/archives/24
We've been plagued for several years by occasional reports from customers about a non-descript error message "Cannot set allocations" that appears on startup of our app. We have never been able to reproduce the problem in our own test environments so far. I have now run out of ideas for attempting to track this down. Here's a collection of observations that have accumulated over time:
Error message text reads "Cannot set allocations" (note absence of punctuation).
The window title simply reads "Error" (or the localized equivalent).
The "Cannot set allocations" text is always in English regardless of OS locale.
I have so far not been able to locate the DLL or EXE containing the message text.
Google is chock full of reports of this error for a variety of different products - but no solutions.
The only unifying aspect between the affected products I could make out so far was that they all appear to come in the form of DLLs that load into third-party processes (such as addins for Visual Studio or Windows Explorer shell extensions).
Our app is actually a shareware COM-addin for MS Outlook, written in Delphi (i.e. native code - no .NET).
The prime suspect in our case is the third-party licensing wrapper that we're using which decrypts and uncompresses our DLL into memory on the fly. Obviously I couldn't simply give an unprotected version of our app to the affected customers to verify this suspicion. Maybe the other vendors that this has been reported against are using similar products.
Debug versions of the protection wrapper supplied to us by the licensing vendor yielded no results: The log files looked exactly the same as from sessions where the error did not occur. Apparently the "inner" DLL gets decrypted and uncompressed all right but for some reason still fails to get loaded by the host process.
By creating an unprotected "loader" DLL we have been able to pinpoint the occurrence of the error somewhere behind the LoadLibrary call that is supposed to load our DLL into memory.
Extensive logging and global exception hooks in our own code (both the unprotected loader and the protected "core"-DLL) yielded no results at all. The error is obviously raised somewhere else.
The problem described in this earlier question of mine was very probably prompted by the same issue. This was before we created the unprotected loader stub.
The error only occurs at about 1-2% of our customers - whereas typically all installations at any affected customer's site are affected the same.
Sometimes the error goes away after we release a new version but often it will come back again after a couple of weeks or months.
Once the error has started to occur on a machine it does so consistently.
The error never occurs while connected to the affected machine via remote access (e.g. VNC, RDP, TeamViewer, etc.) and none of the affected customers are within travel distance from us so all we have to go by is log files and "eye-witness reports".
One customer reported that the error message dialog apparently was non-modal, i.e. he was able to simply move the dialog box to the side and continue working with the application (minus the functionality that our DLL would have provided). Not sure whether this is universally true in all other occurrences, too.
In some cases customers have been able to permanently rid themselves of the error by disabling or uninstalling other addins from other vendors that were sharing the host application with our own product.
The error has so far been observed on Windows XP, Vista and 7.
During the last few weeks we had a surge of reports from Outlook 2003 / Windows 7 users. Could the situation have been made worse by a recent Windows/Office-update?
Does anyone have any experience with this error at all?
Or any more ideas for investigating this?
I have only recently had this happen, which prompted my search and I ended up here. I can tell you that with me for sure it is in windows 7 home premium BUT ONLY WITH IE9 (which I hate by the way) it reduces the user back to the dummy stage and assumes that we have to be repeated flagged about everything.It will keep asking you if you want to disable add ons to speed up load times but usually on things that aren't really the things slowing the browser down in the first place,it is there is too much garbage loading in the first place.But back to the "Cannot set allocations", I for one have never expirianced it in any other browser which is not to say it doesn't happen with them.
This is going to be pure guess-work, but it sounds like maybe your third-party licensing software is trying to load your DLL at a particular location in memory, which - on these failing systems - happens to already be occupied by something else, perhaps a global hook DLL.
If you have a customer who is willing to work with you a bit, it might shed some light on the situation to get a crash dump (e.g., with ADPlus or maybe simpler with Sysinternals' ProcDump) when the error message is showing. That would show what modules are loaded and possibly the callstack (if it is from a message box at the time of the error as opposed to one that is catching an exception after the problem).
I also have experienced the "Cannot set allocations" issue. Royal pain. I had disabled Java, since I did not seem to need it, I used add/remove programs to remove Java from my system. Then I stated to get those errors. I have reinstalled, but disabled Java in IE explorer. Now I do not get the error anymore. Not a programmer, don't know why this happened. Maybe a clue for someone.
Win 7 - 64bit OS IE Explorer 10. Hope this helps someone figure this out. John
I've seen this happen. In my case a global hook dll created a large memory file mapping, perhaps to the memory the licensing dll was counting on.
I see "Cannot set Allocations" when I open google chrome only. Also after that, chrome closes with a msg saying "Whoa chrome has crashed..."
Still no solution :(
Also not a programmer, but it always happens when I open Chrome. It opens second window with error message 'cannot set allocation'. I usually close it and go on my way. if i don't it usually causes a crash. doesnt happen on any other browsers.