Azure has been acting very strange. Previously, all was fine until an update for my cloud service took more than the usual 20 minutes. I then decided to delete and redeploy, however not preserving the previous certificate.
So I repackaged and redeployed; however this time I was unable to connect to the web app via the usual http://youraddrhere.cloudapp.net. Every time I do that Chrome disappointingly tells me: ERR_CONNECTION_TIMED_OUT. When I remote into the cloud service and open the app from within IIS (i.e. its internal IP), it miraculously works! But there is no use if I am unable to expose my cloud service as a public site...
A quick check through my errors in the Event Viewer shows the following:
A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0x8009030d. The internal error state is 10001. I have tried deleting, creating, uploading, deleting, recreating, and re-uploading numerous .cer and .pfx files but to no avail.
What am I doing wrong this time round?
Try to delete the deployment and re-publish your cloud service.
Thereafter, my friend and a colleague RDPed into the Cloud Service and tried all sorts of methods to diagnose the issue, but saw none. There were no glaring issues in the Event Viewer, no endpoint binding conflicts in IIS, nothing wrong with the memory management. Overall, no problem at all.
His suggestion was then: to recreate a new Azure deployment project (.ccproj) from scratch, add in all the relevant roles, and attempt to republish. Initially I was skeptical, but deployment proved successful and as of now I am able to navigate to my cloud service both from within and outside.
I only attempted this when I had utterly no clue what the issue was-from past experiences however the Event Viewer will prove to be a great starting point for any of your headaches.
Related
We have a secured & authenticated WCF service which cannot use service references. Thus, we provide the interface for the contracts and open client channel manually.
We have found out that as long we open it once, everything works fine. We can call several methods several times. However, if the channel is closed or just set to a new instance, the Login() (which happens to be required for first step prior to using the service), times out.
To make the matters even more mysterious, this only happens on our production server. If I run the same project locally, I am able to login many times as I want. Consuming the methods inside a web browser (even on a code-behind ASPX page) do not have this problem even with the production server. ONLY when it's a .NET client trying to open a client channel against the production server, do we have this problem.
We are not even sure where to start looking. Any advices would be greatly appreciated.
UPDATE:
As per #Rene's suggestion, we turned on logging on both sides. From client's log, there is a record of error which is basically the same timeout error we already got via the exception. Nothing meaningful. On the server's logs, there are records of service methods being invoked successfully even after 2nd login() and from server's POV, the request is served.
Additionally, I discovered that I could not even reproduce this issue on my machine using same test project to reproduce this problem. This reproduces on my developer's machine. I verified that we were at same version of .NET framework and Visual Studio. It has to be surely a client-side problem. What could be it?
In case anyone else is looking for answer, we finally found it -- the issue is due to the need to set on client's side System.Net.ServicePointManager.DefaultConnectionLimit to some higher value. The default value is 2 but in reality this allows only one proxy to be created and be usable. Setting it to 3 would allow 2 proxies to be created & be used.
Our asp.net app was working fine, then the DBA decided to encrypt the db password in the web.config. Now I'm getting this error:
System.Security.Cryptography.CryptographicException: Not enough storage is available to process this command.
There is only one other article on SO that has this error listed and the user resorted to a refactor instead of identifying a solution.
The weird thing is that we have plenty of space (RAM, HDD, etc). Even more weird, three of the people on my team don't have this problem (with the exact same url). Another guy had it yesterday, but it works today.
I'm worried about when we move this to prod. Especially, if this needs some kind of incremental storage or permissions for EACH user.
Edit: The other error that seems to show up is:
"Failed to decrypt using provider 'RsaProtectedConfigurationProvider'"
It turns out that this is a generic error message that happens whenever the server has trouble decrypting with RSA. Not very helpful, because it is misleading (at worst) and at best, very vague.
For us, the error was only happening for me because our dev servers are load-balanced (which I didn't know till today). The encryption key was generated on one machine (server1) and installed on both servers. When I got load-balanced onto server2, I see this error (so would anyone else on server2).
The solution is to export the private key from server1 and install it onto server2.
Hi
I've downloaded the Cairngorm3 Simple Sample Application from here.
There's a few steps.
a) Download the server-side zip. It contains a PDF instructing how to start a HSQLDB database and get a Tomcat instance up an running (I used catalina.sh start).
b) Check out the source with Subversion, and load it up into Flashbuilder 4. (You need Flex 3.4 SDK)
When I run the app (an Outlook like app written in Flex), I have issues at the point I try and save a contact. I'm assuming it's on a remoteobject call.
But it I get this:
Send failed
faultCode:Client.Error.MessageSend faultString:'Send failed' faultDetail:'Channel.Ping.Failed error Detected duplicate HTTP-based FlexSessions, generally due to the remote host disabling session cookies. Session cookies must be enabled to manage the client connection correctly. url: 'http://localhost:8400/messagebroker/amf;jsessionid=5765DDDB6E2D54BD03D3E636B0E8C03E'''
I'm wondering if this is something you need to tweak in services-config.xml?
Located in flex-frameworks/tomcat/webapps/ROOT/WEB-INF/flex folder (flex-frameworks comes from the server-side zip download:
Anyone got any ideas?
This is Christophe Coenraets baby.
I also subsequently found a blog post by Alexander Glosband, but couldn't ascertain from it, what you need to do as a work around. i.e. Is this something that is configurable?
The way to reproduce the error consistently is to try and activate the web camera from the app. Then instead of clicking accept, reload the screen. Then when you try and take a photo after subsequently granting access to camera, you get the duplicate session error.
I think there is an issue with the code pertaining to the Camera, that's not cleaning up after itself correctly, the session is probably not being tidied up correctly.
You are right, problem comes from services-config.xml. Change your url from
http://localhost:8400/messagebroker/amf
to
/messagebroker/amf
I found solution from here send failed error
"Compiler EMBEDS channels, endpoints and destinations into SWF" video tells.
When I run a IIS site locally, all site failures (aspx compilation bugs, exceptions in code, etc) are logged to the system event log. I can check the event log to see the HTTP request path and the exception details.
When I run the site on a webhost, I don't have access to the event log. How can I get the same level of error information?
I should be using a logging provided that records exceptions to a database or something. But suppose that code doesn't even get a chance to run, perhaps because a DLL doesn't load. How could I get information about that failure?
On logging:
Did you look at log4net? It separates the action of logging from the medium log entries are written to. You can use a configuration file to direct log entries to a file or database when using the hosting service, while keeping logging to event log when developing.
On dealing with errors:
For errors that occur once that application has started, you can use Application_Error to trap exceptions that otherwise aren't handled. If the application doesn't even start, and you don't have access to the event log, there may not be enough information for you to identify the root cause. It might be worthwhile to deploy locally, to a server or VM that has very little installed on it, to identify missing DLLs and similar issues.
We've got a web system running SQL Server 2005 for the back end, and ASP.Net for the front end (using .net 2.0).
Every now and then, the system barfs out the error in the title: 'SQLOLEDB' failed with no error message available, result code: E_FAIL(0x80004005).
The web system runs just fine 24/7, and then every now and then will toss this out on a select or some such. I've tried re-running the exact select that throws the error, but (of course) it works fine when I do it. And, to answer the obvious follow-up question, no we haven't done any code changes or upgrades to speak of lately.
Has anyone ever run into this before? Nosing around on google seems to only turn up situations where Access has some kind of file issue (permissions, missing data file, etc.)
Firstly, it's probably not SQL Server throwing out the error, and if it is, it's probably not while running the SQL statement itself, but if it is, it's almost certainly going to be peculiar to a login that doesn't have permissions, not the SQL command itself.
The 0x80004005 error is a general permissions failure, and it can occur in just about anything, but it's most likely to be in another layer.
I've seen it in authentication when the account the application is running under does not have access to the network to open a connection to the SQL Server. The SQL Server never even sees the request, but the client will say that the server cannot be found.
If it's intermittent, that could point to an intermittent domain controller issue, but that would depend on how your Windows Servers and Active Directory are set up, and how your application is connecting to SQL Server.
To solve this one, your netadmins will need to really know their Windows logging functionality and track it down for you.