I have a brand new VS2010 installed on a Win2008R2 machine.
I started getting this error when debugging a WCF service project:
"Attempted to read or write protected
memory. This is often an indication
that other memory is corrupt."
When I started developing a web site a week later, this became consistent - I can't debug it.
The stack dump reads:
at
Microsoft.VisualStudio.WebHost.Host.ProcessRequest(Connection
conn) at
Microsoft.VisualStudio.WebHost.Server.OnSocketAccept(Object
acceptedSocket) at
System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object
state) at
System.Threading.ExecutionContext.Run(ExecutionContext
executionContext, ContextCallback
callback, Object state, Boolean
ignoreSyncCtx) at
System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at
System.Threading.ThreadPoolWorkQueue.Dispatch()
at
System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()
I tried searching online, and some recommend turning off the "Suppress JIT Optimizations" in the Debugging options - this dos not seem to make a difference.
Clearly the problem is with the built in web server. But am I doing something wrong? Is there something I can do? Or is this a known bug?
Thanks for your time,
Guy
Update 12/31: Today I tried using CassiniDev as a replacement to the original VS2010 WebServer - exact same result. My suspicion is that there's some internal conflict between VS2010, Windows Server 2008R2 and maybe the fact that it's a 64 bit OS. I switched to using IIS as my debug server - and that seems to work, with some annoying side effects.
My conclusion: do not use a 64 bit server system as your dev machine. Develop on 32bit - deploy to 64bit.
Side conclusion: there are some scenarios Microsoft's QA doesn't test.
Well, here's the sad truth, and I verified it with someone who works for Microsoft, with these very same technologies. I just triggered some sort of Cassini bug. He suggested I try installing VS2010 SP1 beta (which I cannot do since my code is due in production). His other suggestion was to try IIS Express. MS is trying to move people over to IIS Express and provides it as part of their web platform installer - so it stands to reason they will not be spending too much time plugging Cassini bugs.
Since I was using a 2008 server, I just added IIS (takes less than a minute), created a virtual directory (the VS project page allows you to do it with one button click) and I'm now successfully debugging on IIS. Not the result I wanted, but you can't always get what you want :)
Installing .Net Framework 3.5 fixed this exact problem for me.
Hope that helps! Sorry I can't offer any additional insight as to what exactly was going wrong with cassini, but I suspect it was missing a library or two.
====
Update:
Seems to have helped (no longer crashes on the first request), but upon further use I've come across another place where the same error crops up.)
====
Update:
And now I can't recreated it anymore. Best of luck, and if you discover any more please post!
The thing that gets my attention is Win2008R2 and Cassini.
I'm just guessing, but it makes me think that it could be a permission issue.
Is it possible that your Win2008R2 machine is locked down more than your average developer machine (the average developer machine being XP / Vista / Win7 etc).
Perhaps Cassini when launched under your user account on Win2008R2 does not have enough permission to do its thing. Perhaps it cannot open ports? But I wouldn't think a port issue would cause a crash. Or perhaps it doesn't have access to the temporary directories it needs?
Perhaps your user account is denied the permission to debug on the local security policy? But i'm not an admin, so i'm not certain on this.
Maybe try launching visual studio as an Administrator (just incase, to help you investigate the problem).
Or perhaps try starting your site without debugging to help see if it's some sort of permission issue with debugging processes.
I came across this, it's from some time ago talking about Windows 7 and Cassini. http://msmvps.com/blogs/rfennell/archive/2009/01/24/problem-hosting-wcf-using-cassini-on-windows-7.aspx But it may not of been fixed.
Related
I have a Clickonce app from Visual Studio 2015 SP3 that is published to the network server and used in-house only. The program works just fine when launched from Visual Studio. It runs just fine on a Windows machine that does not have the 1803 update. But once a machine updates to 1803, the application no longer starts. I get the "Checking for updates..." window then nothing. On a fresh install, I usually get the Smartscreen telling me the program may be dangerous. It doesn't get that far.
I've created the Clickonce from a computer with the 1803 update and the problem still exists.
I've disconnected the machine from the network. The application starts but then has no database access and it needs the database. It's also written to hide buttons that would use the database to prevent users from trying to do things that require it.
I found a workaround (third paragraph) at https://social.technet.microsoft.com/Forums/en-US/7cbd16f5-526e-4b0b-a186-3ebf41b7b349/smartscreen-prompt-does-not-show-for-clickonce-app-since-windows-10-update-1803?forum=win10itprogeneral. When I start the application from the directory mentioned, I get the Smartscreen and can tell it to run anyway. Every time I click the desktop icon, it works just fine.
If a new release is published, the new release is downloaded and the program updated, but the Smartscreen no longer appears and the application never starts.
So somewhere between installing the latest update and the Smartscreen, this is failing. Anyone else experiencing this and have an idea as to why?
Yes, frustratingly I also experienced this today. Presumably a security update that they'll release another patch for given this is quite a pain for developers and users of small business apps.
Rather than disable Defender or SmartScreen I chose to add my deployment website to the Trusted Sites in Internet Explorer and that then re-instated the warning dialog and my app updated and ran as before.
Really annoying given the nature of the issue and how long it took to figure out, but at the same time I had to use IE today, which is a rare event nowadays.
This works for me...Warn doesnt warn anymore...
After running in the same problem, I just found that my application was going to halt after a stupid uncaught exception.
Despite the fact that the image below is in Portuguese, Event Viewer shows the right error cause.
In my case, was a corrupted settings file!
It appears as though some subsequent Windows Updates have fixed the issue on several of our PC's that were previously experiencing the issue.
Check for the updates listed here.
https://www.catalog.update.microsoft.com/Search.aspx?q=KB4338548
Running winver.exe will show you which build you have.
TLDR; VS2012 throws an exception like below when trying to edit XAML in the Designer running VS2012 as a RemoteApp.
Right, I may be asking this in the wrong place, but I'm at my wits end with this.
Basically what I'm trying to achieve is to run VS2012 on my Surface RT for quick edits of Windows Store apps. The way to do this is to run it as a RemoteApp which actually works great considering you can just hit F5 to build and launch for debug directly on the Surface, the problem is that the VS Designer bombs and throws the exception below.
For initial lab tests I was running VDI as a Session mode setup - i.e. VS2012 was running on WS2012, this gave the exact same exception as described herein. But after discussing it with some people way more into VDI than me we came to the conclusion that it was because it was running on WS2012 and not Windows 8. So I went ahead and changed things around running VDI in virtualization mode.
Said and done I spent a day installing and tailoring a Windows 8 Pro image with VS2012, various SDKs and whatnot. When it came to sysprepping this I ran into a different issue in that sysprep would bomb out with a "fatal error", after another day of trawling through the web and speaking to support it was decided this was because the pre-installed Windows Store apps had been updated. So another day gone reinstalling everything, this time sysprep worked fine and I was able to commission the virtual desktop, however when it came to publishing Visual Studio (among others) as a RemoteApp again I ran into issues. After another day and a half googling, binging, tweeting and finally calling support it transpired this was because only Windows 8 Enterprise edition could be used for RemoteApp publishing ... thanks MS, you couldn't have made this clear in your "best practices"? Anyway, spending another day reinstalling windows and all apps, SDKs and documentation. This time I am finally able to both sysprep, commission and publish RemoteApps. Yey, I'm a happy camper seeing as I should finally be able to do what I set out to do - quick XAML edits and debugging directly on my Surface RT.
Not so.. as the exception is, some five hundred reinstalls later still rearing it's ugly head. The "gurus" I initially spoke to are as stumped as me and can only offer that "it should work" and "it worked fine for the person I configured it for".
So, any ideas greatly appreciated here. While I can use the text editor to edit the XAML and Bob's my uncle in terms of quickfixes and debugging sessions I would much prefer to have it working properly and to be able to use the visual designer (or Blend - as the same exception is thrown there) for certain changes.
This is the actual exception;
2
I had the same problem and I just found a solution.
I had the Windows 'explorer' shell deactivated because I am using BBlean (an alternate shell for Windows, based on BlackBox). Apparently this was blocking the app manager. Disabling BBlean and starting Windows normally fixed the error.
So if you happen to be using a replacement shell, try disabling it.
We are working with Visual Studio 2010 and Team Foundation Server 2010. We did not have any problems for about half a year, but:
Since a couple of days we get the following error: Team Foundation services are not available from server (...) The remote name could not be resolved; (...)
The problem occurs randomly (we are unable - yet - to pinpoint the conditions on which it occurs) and persists until we restart Visual Studio. The problem occurs about 8 times per day per developer.
Because we seem not to get past this problem and we cannot find anybody writing about this specific combination (the error and the 'remote name' part), I thought it wise to ask you guys about it ;) . Could anyone please help?
This is a client, server or infrastructure related problem on network level. The DNS entry for your TFS server cannot be resolved correctly at times for host dfz-vm223.
Suggestions for troubleshooting:
On some developer systems, replace the hostname dfz-vm223 by the ip-address of the TFS server. If the problem stop occuring there the DNS system is instable.
Setup a continuous ping stream (ping -t dfz-vmm223 from command window) and see if the host system is pingable in case you have TFS server problems.
Just found out what the problem was: the problem is proxy related. When we disable our proxy, the problem is gone. It appears our proxy and TFS are troublesome together. If anyone experiences the same problem and you are working with a proxy server, I would suggest you try disabling the proxy too.
I had the same problem, although I'm using VS2012 and a WAN connection to TFS.
I solved the problem by flushing the DNS cache.
To flush the DNS cache, start a command prompt with admin rights: ipconfig /flushdns
You need to do this in all the computers where the problem occurs.
I know this is old, but I had this problem sometimes when I ran Fiddler.
Sometimes Fiddler would crash or not clean up properly and the whole machine would get into some weird state where not even reboots were helping. The solution to it usually is to start Fiddler again, turn off any interceptors/collecting traffic and shut it down again.
Some of my co-workers and I had this problem as well. Out of about 25 developers, most never got this error. But three of us got it pretty consistently. The symptoms are identical, but we are using Visual Studio 2013 almost exclusively. In this version of Visual Studio, the error is preceded by the code: TF400324.
We found eventually that the three of us had all installed Productivity Power Tools 2013. And the developers that were not affected by this error had not installed it. Most had not heard of it. This used to be a very popular extension, so I have always installed it as I set up my system since about 2007. But apparently, in its modern incarnation in Visual Studio 2013, perhaps in combination with some quirk in our network or something, it can cause this problem. We have each uninstalled it, and have not gotten this error since. (It's been several months now.)
If you have this extension installed, you probably already know about it, because you probably installed it yourself. You probably started using it years ago, and it became a habit to add to each new installation. You will find that today, the default installation of Visual Studio actually includes most of its features already. To uninstall, go to Tools --> Extensions and Updates... Then click on Productivity Power Tools 2013, and click Uninstall.
Hade the same issue. For whatever reason the windows DNS Client service on my PC wasn't running. Changing it from Disabled to Automatic solved this problem for me.
Too long for comments:
First off, as #kroonwijk stated, this is an infrastructure issue. Your DNS queries are either timing out or the DNS server is not responding at certain times.
In a comment you mentioned a change over from regular machines to laptops for your entire dev team. If I had to make a bet I'd say that the DNS configuration on the laptops is not the same as what you had on the other machines.
You need to take this up with your infrastructure people. If you still have access to the older machines boot one of them up and compare the IP configuration. If not, get them to fix the problem. The DNS resolution problem could be any one of a number of factors. For example, the new machines could be pointing to an incorrect DNS server that has network issues or their might be some incompatibility between how Win7 makes DNS requests and your DNS server.
I have also experienced this problem and it doesn't always have to do with name resolution.
If you add an entry to your %systemroot%/system32/drivers/etc/hosts file for your TFS server, it removes any dependance on your name resolution servers.
If you are still experiencing the problem, then it has to do with either visual studio or one of the VS Extensions that you are running. There may be a memory leak somewhere. Disable all your Extensions using the extension manager, restart VS, and see if you still experience the problem.
I am getting very annoying message called "system.outofmemory.exception" while I do have a lot of unused memory in my laptop. Unless I closed and re-opened the solution, it won't letting me to continue my work.
Is there any configuration or service pack that can fix the issue ?
Thanks
My Solution was was fine in the Visual Studio environment.
But when I was trying to execute tha builded project I was getting System.OutOfMemoryException
After few hours I change the my Comodo Antivirus Settings. I made the builded solution as trusted file.
After that I did not have this problem any more.
Maybe it help you... too
Try reinstalling VS and run a memory check. If there's any update that is able to correct an issue like this, it's maked as important on Microsoft Update, so be sure to run it and select all the updates marked as important. Also, check if running VS as administrator solves the problem, sometimes a normal user has some limitations (on business' networks it's possible that the IT limits memory usage by program, and windows 7 has some new security policies that I'm not sure how they work yet but running a program like adminitrator usually solves the problem).
I have this issue on a daily basis on a WinXP with 4GB of RAM (only 3 utilized, obv). As soon as VS 2010 Ultimate closes onto 700 MB of memory usage, I start getting OutOfMemoryExceptions. Only redemption is to restart VS, even if I close other memory-consuming applications. I also notice that the problem sufaces faster if I run unit tests. Probably because this is a memory-intensive task.
I see two separate issues here.
Visual Studio reporting out of memory when there really is available memory in the OS.
Visual Studio goes into a malfunctional state after the exception, unable to acquire new memory freed by the OS.
1) may be OS-related and not VS, I don't know enough about memory handling in Windows XP to be sure about this. I belive 2) is a VS-problem and should be fixed.
VS reinstallation is temporary solution. Jus increase your machine Virtual memory size. this resolves this issue.
ref below link -
http://windows.microsoft.com/en-in/windows/change-virtual-memory-size#1TC=windows-7
This is trouble shooting question.
Our application's development environment is VS2005 C/C++, VB6 based GUI.
we use also componentone for ActiveX control(vsflexgrid8).
application performed well in Windows XP, but in Windows 7, there is some problem in GUI.
rebuilded almost all C/C++ code and VB6 code in Windows 7
our build system is so poor and because I joined this team a month ago, building all codes are a bit hard
But this (maybe) last problem is not related to build, I think.
all other processes and GUI process are start well. but when click some menu in GUI, all user controls become invalid.
error message seems like this:
'-2147417848 (80010108)' occured
runtime error.
Automation error.
Invoked Object disconnected from
client.
above message is not identical to real message since real message is our native language(Korean).
when googling with this message, I'm able to gather some informations.
the most possible case is when using OLE Automation for Microsoft Office Objects.
But our GUI(VB6 developed) does not use Microsoft Office Objects.
And problem-causing page/control's are commonly use componentone modules.
So, if experienced similar problems, please help me.
In Virtual Machine Windows XP mode, there is no problem. But I'm strongly willing to develop in this environment.
Thank you for your help.
'Automation Error' just means that an error was raised from within the ActviveX control, but that the developpers did not add a description to it. So the cause could be anything.
A common source for this kind of errors are write errors to protected folder (The Program Files folder for instance) or forbidden Registry Read/Write actions. You could try installing the program to another location or to run it elevated.
Hope this helps at least a little.
As Dabbler says, this means there has been an error in the ActiveX component.
Does any of your C or C++ code run before this error happens?
Are you using the latest version of the ComponentOne control? Perhaps it's worth checking whether it is supported on Windows 7, and contacting their technical support?
You could debug the VB6 and C/C++ on Windows 7 to track down which bit of code triggers this problem. This is possible with Visual Studio 2005, which you say you have, or WinDbg which is free.
I solved this problem by Windows Updates.
Since about 20~30 updates are performed at once, I can't know what update solves this.
I guess Visual Studio 2005 security updates may the reason for this trouble.
Anyway, my application runs well in my Windows 7 machine.
Thanks to All.