Alright StackOverflowians, this is a strange one, so bear with me and be kind. Also, this may be more of a question for ServerFault, but I'm hoping other developers out there may have seen this behavior and / or have some insight.
I have a VB6 application (custom built but the source code is long gone) which is running on a Windows Server 2012 R2 VM. When I connect to the VM using an RMM utility (ConnectWise) I can run the application as expected and everything is happy and good. However, when I connect to the VM over traditional RDP, the application crashes on startup and cites the error as COMCTL32.DLL, Exception Code: c0000005. I login as the same user in both scenarios.
I believe that this did work over RDP once-upon-a-time, but it's been probably 6 - 8 years since I've done this.
I've been finding information about the exception code listed above as an "Access Violation" and have followed some steps to disable Data Execution Prevention, but this had no effect. If I wasn't seeing this with my own eyes, I would not believe it is happening. Would welcome any tips or information, especially if you've seen similar behavior before.
Related
I'm having a very strange problem with an application in windows 10. It consists of several .exe in the same computer communicating between them with sockets using system.net.sockets library.
The problem I have is that after installing Windows 10 in a new computer, install all windows updates and then installing that application, connection to sockets doesn't work correctly and the application fails. The strangest thing is that if you leave the computer alone for 1-2 days the applications starts working just fine. The same has happened after installing version 1803 update, it stops working and then works one or two days later.
Any idea of what can it be? Has anyone seen something similar?
It really seems to be related to the 1803 update you mentioned.
Symptoms:
Running an application from a network share will fail when creating a socket;
Copying the very same application to a local drive/path will work just fine, without any further modification.
We are also struggling with this while connecting to an Oracle database (both ODBC and ODP.NET) and it seems the issue has recently been acknowledged:
https://support.oracle.com/knowledge/Oracle%20Database%20Products/2399465_1.html
It also seems this is a recurrent Windows bug:
Win Socket Creation fails with Error code 10022 if non super user
https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/3076a9cd-57a0-418d-8de1-07adc3b486bb/socket-fails-with-error-10022-when-application-is-run-from-certain-network-shares-on-vista-and?forum=wsk
Sorry, no effective solution at the time (other than copying the app binaries to a local folder). I'll update this answer once we get a better solution.
OK, looking a little further I found here in SO that this might be related to a SMBv1 network share, which describes the environment we had here (the network share was disabled because of another bug we faced - thanks MSFT).
Re-enabling SMBv2 / SMBv3 on the server solved the issue.
Related post:
After Windows 10 update 1803 my program can't open a socket when running from network share
I've a Perl script that forks in order to use Win32::OLE to extract PNGs of slides from a Powerpoint presentation. I'm in the process of migrating it from my old server (Windows Server 2003) to a new server (Windows Server 2012). The script works fine on the old server (which has Microsoft Office 2010) but on the new server (with Microsoft Office 2016), the script bombs with an error about there not being enough storage available:
Win32::OLE(0.1712) error 0x8007000e: "Not enough storage is available to complete this operation"
I've found quite a few references to this error code, but none particularly useful. Whilst this Microsoft support article says what the problem is and what to do to fix it, I have no idea why this is suddenly an issue now I'm moving to a different server and it doesn't seem to apply to my situation.
The new server has loads of spare disk space and RAM, so there should be plenty to go around. (The old server has far less of both, but that still works.)
Could this be something to do with the new server being 64-bit?
Could it be because of the differing versions of Office?
Could Apache or Perl be configured differently by default than when installed on the old server? (It's a new installation of each, but from the same source as on the old server, and I can't find any configuration that limits memory.)
One interesting point that leads me to believe that it's something to do with the script running via Apache (v2.4.27) is that if I run it from the command line (requiring a minor modification), it works fine. Apache runs as a service and I've tried running it as the same user for which it works on the command line, and that has no impact.
I've run out of places to look and things to try now, so any help would be appreciated.
UPDATE (21 August): Since nobody seems to have any ideas, I refactored my code slightly so that it gets called via a scheduled task. That works fine, supporting my theory that it's something to do with it being run via Apache. I'll keep this question open, partly in case a solution is presented and partly in case my workaround can help anyone else who has a similar problem.
I have an old web application which formerly ran on a windows 2003 server. When I moved it to a new Windows 2008 server, I started receiving an error that I never had before. The app uses a windows login. Upon accessing the app, the user is asked for their login. After that, they are free to use to application. However, the issue is that after using it for some time, the user will be booted out and asked to login again. The system is also much slower than it was previously. It is operating on IIS7. It seems to me that there is a loss of session variables occurring, but I am unsure about why that would be the case.
Interestingly, when the user logs in again, they can generally use the application for a longer period of time before being booted out and asked to log in again. It is also worth mentioning that it seems like the more users there are on the server, the less prominent the issue is.
It is also worth mentioning that I tried moving the application to another 2008 server, and it worked perfectly fine on that one. This leads me to believe that the issue lies somewhere in the settings on the server. I looked at the settings of the two 2008 servers side-by-side and noted the differences, but was incapable of finding a difference that would cause this sort of error. One difference that might be worth noting is that the server which does not work properly is 32 bit, whereas the server which does works is 64 bit. Although, I don't see how that difference could lead to the application having a loss of session variables, but still working otherwise.
Additional information:
The code in the application on each server is identical, so that leads me to believe that the error is on the server level and not within the application itself.
Given that the code is identical, I do not believe this to be a result of Session.Abandon() being called from anywhere.
I do not believe this is due to a session timeout.
I have read that other people experience a loss of session variables due to app pool recycling, and that often the app pool recycling is from the config files being accessed (whether it be from a user or from something like an anti-virus software). I have no reason to believe that this is the case here, because all servers are under the same anti-virus and the application works fine on them.
On the server which works, the IIS authentication setting are set such that windows authentication is disabled and that anonymous authentication is enabled. Whereas, on the other server, the opposite is true.
Any help with this issue would be appreciated.
Thank you.
Make sure your app pool is running under 4.0 .Net Framework and also check your application pool identity. When your using 7.0 iis, make sure you use integrated mode.
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.
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.