I have been using a publish profile from Visual Studio to publish my web app for about a year. Over the past week or two the process gets stuck and does a few retries until it fails. The error I am getting is:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web\Microsoft.Web.Publishing.targets(4295,5): Warning : Retrying the sync because a socket error (10054) occurred.
2>Retrying operation 'Serialization' on object sitemanifest (sourcePath). Attempt 1 of 10.
Points to note:
Nothing has changed on my network
The publish profile is version controlled and is the same
The publish doesn't fail from the beginning. It publishes for a while.
Seems to fail if the file is bigger than ~10 or 15 MB
Others who have this issue, seems to be their ISP or their network but
it seems theirs fails from the beginning.
Tried it with two different publish profiles on two different subscription accounts resulting the same problem
Anyone has seen this? any ideas?
Finally, the issue is resolved. I had checked every bit, including calling my ISP, and didn't have any luck. Thanks to #rickvdbosch for mentioning the TCP/IP relevance to this problem that juggled my memory.
A few weeks ago, I upgraded the firmware on my router (as I am using DDWRT). I believe that was the culprit. I did upgrade to the latest DDWRT firmware and I see the issue is gone. It is deploying as before all the drama started.
So if another poor soul comes across this error, wish you luck but be aware of this possibility.
Related
A few days ago I had to update our .NET Framework 4.8 web application. First it could not be builded because of some TeamCity error on the newest version, link here. After that it could be builded but since then it showed us a custom errorpage after deployment -> 403 - Forbidden. I just changed a string ("exec X" to "exec Y") so we can access a better and faster SQL procedure.
Removing the tiny piece of argument it suddenly succeded in building anyways but the HTTP error still was there.
Neither IIS, Server, Framework Version etc. was updated, only TeamCity and that small code and argument change.
Reverting the changes to the version which had been working fine did nothing.
After a while I found out that it is a 403.14 error and static files can be accessed, but Microsofts help page didn't help a bit, it just showed the directory -> look here.
After that, I decided to shutdown and backup TeamCity and install an older version of it -> Nope.
Searching google and stackoverflow for similiar problems I stumbled upon to this post especially where I tried every single answer. Before I answer further questions on about what I had tried, please read it.
Since nothing helped so far I decided to try something "dumb" and publish the project to the folder and copy the data manually to the server and voi la! It worked! But I don't know why
and also TeamCity still can't do it anymore.
No changes were done to AppPool or other settings, please keep that in mind.
Here are my build settings from teamcity:
Please don't mind missing build steps, since those are either uninteresting or disalbed because some of them I had created to test the failing deployment on our test system.
And also, when running it locally or copying published project works fine..
Problem was with the antivirus blocking some processes, so some Asax_global.dll was missing.
We've recently released our app to our userbase and we are seeing a bunch of redacted exceptions in Sentry that we can't debug in any logical way.
The only thing these exceptions seem to have in common is that they never happen when the application is active:
And the available memory seems to be very low on these devices:
One theory we have is that the OS decides to close any background applications due to low memory available.
But it's quite a assumption to make at these point when I'm more inclined to believe we have made a mistake in our own code.
To my questions, how would we go about debugging these redacted exceptions? Are we right to believe that our app being closed when it's not active is no cause for concern?
The on-premise version of Sentry have several issues related to this specific problem. According to the Sentry team these will be fixed in a upcoming release for the on-premise version. But to summarize.
At first we had difficulties getting the upload scripts for the dSYMs to work. The Fastlane lane mentioned here did not work at all. Neither did the bash script that was prompted in the Sentry interface under debugging symbols.
What did work was using the sentry-cli (latest version) and bumping up the accepted file size for upload on our nginx server for our on premise. But after successfully getting our dSYMs file to actually show up in Sentry we had more problems.
The issues we've encountered are listed below:
A required debug symbol file was missing
#johan12345 Sorry for getting back to you so late. We've verified your debug symbols and can confirm they should process and symbolicate correctly. The issue you are referring to has been fixed a while back in both sentry-cli and sentry and will be available with the next release.
We have been preparing a major launch over the last couple of months which is why there have been no releases recently. However, since we've received a couple of requests regarding symbolication for on-premise customers, we will try to push a new release out soon. I cannot give you an exact timeline, though, so please stay tuned.
Again, I'm very sorry for the inconvenience this might have caused.
https://github.com/getsentry/sentry/issues/7595
Reprocessing 12 events …
Some users are reporting sometimes to be stuck on reprocessing. Mostly happens with self-installations but we also had two support issues.
This seems to be triggered by internal server errors in the processing pipeline in bad places.
Related: https://forum.sentry.io/t/stuck-there-are-x-events-pending-reprocessing/1518/6
https://github.com/getsentry/sentry/issues/5862
We've added a new button called "Discard all" which can be found above your processing issues list.
This will discard all processing issues and the corresponding events.
We've also found an error in our processing pipeline we've yet to fix.
I will close this issue for now and link new issues regarding processing errors later.
So the only thing I can advise you right now is basically deploy the master branch of Sentry because our last release was in November and we fixed a bunch of stuff since then.
Not sure if we release a new version before Sentry 9 (which still needs some time).
https://forum.sentry.io/t/ios-exceptions-shows-up-as-redacted/3681
TLDR: We are switching to Crashlytics
I have embarcadero radstudio xe8 on a windows 10 machine. Everything was working perfectly till about 2weeks ago. Everytime I try to start Delphi xe8 I get an error :"Exception EOSError in module rtl220.bpl at 00050A4D.System Error. Code 111. The file name is too long. " I tried reinstalling a couple of times and I even tried installing appmethod but I still get the same error.
What can be the problem?
I've had the same issue today. I've traced it to a GetAdaptersInfo() call, and it turned out that for some reason (VirtualBox is my main suspect) I've had over 50 network adapters registered on my system. Removing all of them fixed the issue.
There is not enough info in your question in order to tell what exactly is wrong. Try using Process Monitor in order to check what files Delphi is trying to access. It will also show the errors of these file operations.
as they uri2x tell you the problem is that RAD Studio having issue with many network adapters registered more than 20 will not work properly you will have problem with debbuging and run project and you may find many cmd.exe process running in your system
delete duplicate and non needed network adapters registered on "Control Panel\Network and Internet\Network Connections"
that will fix your problem
This may be of help. I had a similar problem, error code 5 Access is denied. This turned out to related to a thread started to test an internet connection on an embedded panel (using BeginThread). If the user exits the form (which is testing the internet connection) immediately after displaying the form, the AV occurs.
On my development PC, the internet connection test was successful...and so fast I never saw the problem! After struggling for several hours, I finally tracked it down to this thread and reproduced it by disconnecting my network cable.
The solution was straightforward: When exiting the form (eg. in the FormDestroy event) ensure the thread is definitely not running before continuing.
Just noticed a strange issue. I can no longer access the blobs (iamge files) that are stored in my Azure Storage Emulator. First noticed that my web role wasn't serving up my files from emulator when running in debug. I tried to access files using a third party app, cloudberry. cloudberry lets me browse the storage emulator container that I created, but when I try to access a file it fails. Both my app and cloudberry fail with
500 error
returned... not helpful.
Tried restarting storage emulator, no luck. Tried starting emulator from Azure SDK command prompt to see if there was an error. started successfully... no error reported, but still having my issue when i try and access my blobs. I have SQL Express installed and I verified that MSSQL$SQLEXPRESS service is running. I have made no recent changes to my web role configurations. I am using Azure Tools version: June 2012. Anyone have ideas on what else I should try?
Thanks!
Gaurav Mantri's comments were helpful for tracking down my error. Examining the error log I found that I'm experiencing a somewhat common issue where my azure storage corrupts itself. I found a informative but inconclusive forum thread on it (link below) if someone is looking for help on the same or similar issues.
http://social.msdn.microsoft.com/Forums/en-US/windowsazuredata/thread/699d8861-b3d3-4140-9cf3-b749a2cfed39/
This issue is also discussed in this SO thread:
Mysterious disappearing Azure development storage assets
In my experience, I've got this problem only the emulators that ships with Azure SDK 1.7 . As you can see from my answer, the problem disappears by using the updated emulator in Azure SDK 1.8 (I've used it for more than 4 months) -- you can upgrade it while continuing to use 1.7 libraries in your cloud projects.
We've got an application written in Delphi that uses Delphi On Rails and acts as a server and communicates with clients using HTTP, JSON and websockets. We ran into some issues lately and it's hard to debug them and find the problem's source.
Using Wireshark for traffic analysis, we could see the following behaviour: There's a request from a client (HTTP GET for a file). Usually, we process that request and send a HTTP status code, the file (if not cached) etc. However, we have a reproducable problem where there's only
the request from the client, a TCP SYN from the server, but after that, the server sends a RST packet and the TCP communication stops.
The strange thing is, we can reproduce the problem quite well (although the files where the RST packet disrupts the communication differ) and it mysteriously vanishes in one of the following cases:
In debug environment (Delphi IDE), disabling madExcept
In release environment, not patching the executable with madExceptPatch
Give focus to a different window than the main application window.
As we had some problems with Delphi On Rails and had to do minor modifications to it to avoid access violations and debug exceptions, I suspect DOR to be the culprit and some strange memory corruption or uncatched exception to be the bug, but it's still confusing, especially the fact that the problem vanishes if we change focus.
My main question is not how to solve this problem, but how to debug it and where to look for problems. The source of the TCP reset also puzzles me, as we don't run into the usual procedures that process requests in that case and it seems like either DOR or something else (the application, Winsock, OS) resets the connection by mistake.
For completeness, as it might be related, here are issues that I reported at the Delphi On Rails project and a forum thread where I asked the madExcept author about the problem: Issue #6, Issue #7, Issue #8, forum entry.
As a test, we checked out some older DOR sources from version control where no connection issues were known, and it works without showing any of the above problems.
So we decided to solve the problem the other way round: Rolling back the DOR specific source code (about 20 files) to the last stable version and "re-updating" it piece by piece until the error will occur again. If this happens, we can
Go back to the latest working version quickly
Hopefully be quite close to the original DOR sources so we can react on updates on the library.
Analyse the occuring error and report an detailed issue (and perhaps even a solution) to the DOR project.
EDIT: We could now update all but one file back to the old state without getting connection issues. The file that creates problems is dorSynchronizer.pas, more exact it's r179 of this file that caused the issues - threads were changed from Windows API to Delphi TThread there. We'll investigate this further and might add an issue to the DOR project in the next days.
EDIT2: It turned out that DOR uses the deprecated procedures TThread.Suspend and TThread.Resume that can cause undefined behaviour. I reported an issue to the DOR project.