About a week ago a program I'm working on began crashing with an AccessViolationException whenever I typed into a certain textbox. I've reduced it to this test case, but I'm out of ideas:
Imports System.Windows.Forms
Public Class Start
Inherits System.Windows.Forms.Form
<STAThread()>
Public Shared Sub Main(args() As String)
Application.EnableVisualStyles()
Application.Run(New Start())
End Sub
Private txtNotes As System.Windows.Forms.TextBox
Public Sub New()
Me.txtNotes = New System.Windows.Forms.TextBox()
Me.txtNotes.Multiline = True
Me.Controls.Add(Me.txtNotes)
End Sub
End Class
When I build this program using Visual Studio, it crashes if I type into the textbox (always). If I build it using vbc.exe Start.vb /target:winexe /main:Start /out:Start.exe, it works fine.
Additionally, I've found that removing either of these lines stops it from crashing using Visual Studio:
Application.EnableVisualStyles()
Me.txtNotes.Multiline = True
I've already done a repair installation of Visual Studio, and used sfc.exe to check for corrupted system files. I've tried searching for existing solutions to this problem, but haven't found anything. What could be causing Visual Studio to build a broken executable? Is there some setting that would do this?
Edit: I'm also running AVG antivirus at the moment. I recall that there was an AVG update around the time these crashes began. As per one of the comments below, disabling AVG, and then scanning the executable prevents it from crashing. This would seem to indicate that the problem lies with AVG.
We have the same problem with a few of our clients' installations on Windows 7. Our product is C# with WinFoms and .net 4.0. Typing in a mutli-line text box under WinForms crashes an AccessViolationException. You can paste text in the box and delete it too, just not type. Single line text boxes are fine. We also found that removing Application.EnableVisualStyles() cured the problem.
Another way to fix it without code changes is to right click the program icon and change the compatibility settings to run the program for Windows 7.
I'm having the same problem, and I'm running AVG too.
As a temporary solution before AVG provides a fix, you can add the .exe file to AVG's list of exceptions. I can confirm that this removes the AccessViolationException shown in Visual Studio.
Open AVG, go to Options
"Advanced settings..."
Exceptions
"Add exception"
Choose "Application or File"
Select your executable file (in my case, I used .../bin/Debug/myexe.exe)
I checked "Even when the file has been changed or updated"
Finally, I checked all of the three options at the bottom: "Resident Shield", "Manual and Scheduled Scan", and "Identity Protection"
I did not perform any change regarding visual styles or compatibility mode, as mentioned in other answers.
I had the same problem. Solved it by unchecking Enable XP visual styles.
Some background in case it helps anyone else. Application was originally created in VS2010. Moved up to VS2015RC. Everything worked fine. Problem occurred after a reinstall of the OS (Win7). Even the old version of the application would not work, although it did continue to work on all the other Win7 desktops, including a new install. If anyone knows why, it would be interesting.
Related
This behavior is in a vb.net web application solution with multiple class library projects referenced by the web app.
The code compiles, but in debug mode, some functions/subroutines in the referenced class libraries have local variables that display
'var_name' is not declared. It may be inaccessible due to its
protection level.
in the watch and immediate windows.
The mouse_over intellisense doesn't work on those local variables.
In some sub/functions the variables' values are accessible until I step into a Try..Catch
All variables passed into the Sub/Function are accessible. Variables defined at the class level are accessible, too.
This behavior is new in code that has been in the solution for years. The scope of the subroutines and functions have not changed (they are Public).
It is not consistent either. In a given class library project, public functions/subroutines in one class will have local variables where you can see their values, while others display the message shown above.
Things I have already tried:
* Clean/Rebuild Solution
* Turn off Code optimizations (it has always been turned off in Debug mode)
* Enable the "Show all members for non-user objects in variables windows (Visual Studio)" option in the Debugging options.
* Import default settings for VS2012
* Update VS2012 to latest version (Update 4)
* Install VS2013 and open solution (behavior occurs there as well)
* Clear AppData cache
* In Advanced Compiler Settings, set 'Generate debug info' to both Full and pdb-only
* Remove local copy of solution and get the solution again from TFS
* All projects in the solution are set to Debug
I have multiple solutions in TFS and this is the only solution that shows this behavior.
I have had a colleague get a copy of the same solution in TFS and the behavior does NOT occur in his local copy.
This behavior did not occur in VS2010.
Here is an example of a method and local variable declarations where this behavior occurs.
If you step through the declarations and set watch on any of the local variables or any statements using the local variables, you will see
'var_name' is not declared. It may be inaccessible due to its
protection level.
as the value of the variable in the watch/quick watch/immediate windows
Utility1.vb
Imports System.Web
Imports System.Text
Imports SPBO
Public Class Utility1
Public oNav_inc As New Navigation_INC
'===========================================================================
'Utility1.vb
'===========================================================================
Public Sub UTIL_EstablishActivityContext(ByRef Response As HttpResponse, ByRef page As Page, ByRef oGlobal_inc As GlobalVariables_INC)
Dim oActivity As ENC2.Web.ActivityContext
Dim oMHardUBO As MHUBO
Dim oPUBO As PUBO
Dim asGroup As String = ""
Dim sGroup As String = ""
Dim bActive As Boolean
Dim g_oUserAccountBO As UserAccountBO
Dim sImplementation As String = ""
Dim rs As DataSet
Dim sQuery As String
Dim rsUser As DataSet
Dim sUserGroups As Object
Dim iLoop As Integer
Dim bInternal As Boolean
Dim g_bInternalUser As Boolean
g_bInternalUser = False
'rest of code
End Sub
End Class
UPDATE: I went ahead and reformatted/reimaged my laptop and installed VS2013. The issue is no longer appearing.
It's not exactly a permanent solution, but I did find a workaround for this in a project I was amending for a friend of mine. Although I couldn't make the bug to go away on a permanent basis, I found that it didn't report these errors if the affected pages weren't actually open for editing.
What I had to do was save them, close them out of the editor, and then compile the project. The project WOULD compile correctly once I'd done that, and after it had compiled, it wouldn't report those errors again even once the pages were opened for editing (though eventually, some edit or other would cause the problem to reoccur -- but each time, the solution was the same. Close everything out, compile, and then reopen whatever I need to edit.)
A few months back I was dealing with exact same issue in VS2013. It is a maddening bug that Microsoft is (last I saw) unable to reproduce. For me, it came and went with no apparent reason. The first few times I got rid of it by doing some of the things you have already tried above. But then it came back and I could not get rid of it. What finally did the trick was uninstalling and removing all traces of all versions of Visual Studio (including a manual sweep of the registry), getting rid of all code, projects, solutions, etc, and removing all versions of .NET.
Then I put .NET back, re-installed VS2013, and got latest from TFS. Since then, it has not come back. Sure hope it doesn't. Good luck!
Try to CleanSolution, it appeared to fix it for me.
When it comes to a WinsForm app written in VB.NET, this can happen if the backing code file for the "{Whatever_Form}.vb [Design]" tab, {Whatever_Form}.designer.vb code file, is corrupted by the Visual Studio designer logic. The control symbol that is supposedly "...not declared. It may be inaccessible..." is declared at the wrong scope within Sub InitializeComponent() within the {Whatever_Form}.designer.vb code file, the "Me." prefix is missing, "Friend WithEvents Foo As Type" statement is missing and/or all of the above. The way to fix it is to directly edit the {Whatever_Form}.designer.vb code file leaving the correct {Whatever_Form}.vb source untouched. Edit all the inconsistent declarations having to do with the symbol of the {Whatever_Form}.designer.vb code file which is listed out using the "Find in Files" Visual Studio menu item.
One thing to avoid to not cause this type of corruption is to not rename the control symbol's property names "(Name)" or event handler procedure names using the Visual Studio Properties tab. Rename symbols from the {Whatever_Form}.vb source file only.
I using Visual Studio 2017 Pro, for a VB.NET WinsForm app targeting .NET Framework 4.7.1.
I have created an application that installs and edits configuration settings for a 3rd party application. The application works fine but I need to prepare it for deployment, which means I need to edit it so that it can run silently. I've created it in Visual Studio 2012, if that makes any difference. It contains 3 Messagebox.Show for errors, that I suppose I should output to the error log, and the "Configuration Complete" prompt after success. There is a single button click to start the configuration function.
I have looked around and found only people trying to silently run other applications silently from within their code. If anyone can point me in the right direction I would be grateful.
Just add a Module to your project.
Change your Startup Object to "Sub Main" in Project Properties>Application Tab
Then add a Sub Main your module:
Module Module1
Sub Main()
'call your program code here instead of from your button click
End Sub
End Module
And yes you need to log your errors to a file instead of showing them in a Message Box
I need a few people to test the below testcase in VS 2010 and VS 2010 Express and please let me know if I am experiencing a possible (and highly annoying) IDE/Code Editor bug.
Create a new VB Project and make it a Windows Form application and add a new module to the project. In the module, paste the below code:
Public Sub Bug()
Dim Ninja As Object = Nothing
Dim Pirate As Object = Nothing
If (Not Ninja Is Nothing) AndAlso (Not Pirate Is Nothing) Then _
Call String.Join(","c, {"one",
"two", "three"})
End Sub
Now, position the cursor before the opening double quote in the word "two". Press the tab key one time, and then press either the up arrow or down arrow.
If the bug fires, that entire line of text will be deleted. It will not fire if the If block is omitted, or the If block uses a closing End If (instead of just the line continuation character).
I am experiencing this on VS2010 Express (VB.NET version). I'll have to try it in VS2010 Premium at work to verify there. I suspect that, if it is a genuine bug, it's in Intellisense, cause the up/down keys usually trigger that to pop up with suggestions. Maybe it gets confused and just deletes the line somehow?
I thought my project file was corrupted, but I tested this in a brand new project and it still triggers.
If it is a bug, where do we report these things?
I can confirm the bug in VS2010 Ultimate Edition.
The line gets deleted. Also when I use backspace instead of tab.
You can report the bug on http://connect.microsoft.com under visual studio
Marcel
We've recently upgraded from VS2008 to VS2010. The conversion of our vb.net Windows Forms app went well, but we're now having big problems with the forms designer.
Pretty much any change to the layout of a form (sometimes just a solution rebuild) will work once, but on recompile, the IDE designer refuses to display the form, the error message being a null-reference exception (with no details as to what).
Closing and restarting VS2010 will cure it, but only for one compile cycle - and it's obviously not practical to close and reopen every time. Closing and reopening the form does not fix it.
We had these very occasionally before, if there was something wrong in the form's load event, or more rarely for random reasons, but since VS2008 SP1 this was never serious.
Whereas now with VS2010, it's now every form, every compile.
It's completely unworkable, and we've had to revert to VS2008 for winforms dev.
Any suggestions would be greatly appreciated..
You can debug design mode:
In project properties, in the debugger tab, set the name of the executable to devenv.exe.
Run/debug the project: this launches a 2nd copy of Visual Studio
Use the 2nd (being debugged) copy Visual Studio to open the form in design mode
You may find more detailed information on the 'net, by Googling for 'debug design mode'.
Is your project Targets to .Net Framework 4 Client Profile or .Net Framework 4 ?
If you are not intentionally targeting to .Net Framework 4 Client Profile then change it to .Net Framework 4 you have a fair enough chance.
If, that was not helpful. Please do the above procedure as ChrisW said. That is the last option.
we faced the same problem. The reason ist, that the Handles statements are not converted
according the control name, but in capital letters.
However the controls themselves still contians the original correct name in lower case
or mixed. They also do this way in the designer.vb code.
You have to correct alle handles in the .vb code to match the name in the designer.vb code
of the same form.
A (fast) workaround is as follow.
a) Load the defective project.
b) Try to open a form
c) Press F7 to open the code
d) Replace all Handles to 'handles (search and replace, it works only form by form this way)
e) start a build
f) replace all 'handles to Handles
g) now the form should open
Unfortunately this works only form by form as VS 2010 'chockes'
loading too many forms at a time.
We are not taking any responsibility for the functionality not for eventual damage of your code using this suggestion!
I have a Windows Forms application in a single project written in VB.NET 2003 (legacy code). There is a MainForm and a SecondaryForm that is run by the MainForm. When I run the application through the MainForm, I can debug without any problems.
However, if I just run the SecondaryForm, I get the debug error:
There is no source code available for the current location
when stepping over:
_routeId = CInt(myVar)
At this point I am no longer able to debug through my code window, but I have to use the disassembled code.
Why does this happen and how can I fix it?
My problem was of the Step-Into kind. I could step into a procedure inside a usercontrol just fine, but when its End Sub was encountered and I was leaving that Sub, I would get the "There is no source code available for the current location." error page.
The solution that personally worked for me was: In the Project Properties page, under "Debug", uncheck "Enable unmanaged code debugging".
I have seen this issue many times... and more often than not it is a reference(s) issue. Is it your code that has "no source" or is it Microsoft code? Do you have multiple versions of the .NET Framework installed?
Double check your references.