I am trying to get an FTP application up and running on Windows Server 2003, before this application was on windows XP professional running with no problem. I have tried googling around for answers, but the only "workaround" I can seem to find on Microsoft’s website didn’t correct the problem (being edit the registry and add a new field DisableRawSecurity with a value of 1(in the correct area). I am debugging this application in VB .Net
The exception: An attempt was made to access a socket in a way forbidden by its access permissions.
As requested here is the source code of the sub its hitting the problem on:
Private Sub Listen()
Try
ListenerSocket.Bind(LocalEndPoint)
ListenerSocket.Listen(100)
While True
ListenerSocket.BeginAccept(New AsyncCallback(AddressOf AcceptCallback), ListenerSocket)
End While
Catch ex As System.Exception
Stop
End Try
ListenerSocket.Shutdown(SocketShutdown.Both)
End Sub
Any help would be appreciated.
You might be having a problem because the call to BeginAccept is in an infinite loop. You should only be calling that once until the AsyncCallback is hit, then call EndAccept and BeginAccept again. So essentially you call BeginAccept once to start, and then again after every connection is established.
Everything in Windows has an Access Control List (ACL). It sounds to me like the user running your application does not have the proper permissions in the ACL to do do what you are asking it to do. I'm not sure how you would go about finding the ACL for a raw socket, but thats where I would start looking.
Are you even using Raw sockets in your application? If not, then that KB article does not apply, and your exception is due to some other reason.
Related
I inherited a program written in VB.NET. I want to host the installer and documentation for the program in a SharePoint Online library. The SPO library allows View/Read-only access to "Everyone except external users" but it does not allow anonymous access. I want the program to check the SPO library for an updated version when it launches.
I envisioned a simple function like this:
Private Function getVersion() As String
Using client As New WebClient
getVersion = client.DownloadString("https://companyname.sharepoint.com/site/library/version.txt")
End Using
End Function
where version.txt contains nothing but the current version number.
However, this function throws an IOException stating that the connection was forcibly closed by the remote host. I think this is because the SPO site requires authentication.
I don't want to add a user login step solely for this one thing. This probably means an SPO site that requires authentication is not the ideal place for my version.txt file to reside, but I'm also trying to avoid solutions that require me to jump through hoops and involve others to get it to work. I'm the only developer for this program, so I'd like to be able to publish an update without having to wait for someone else to do something (like update a web server that I don't have access to).
Suggestions for a simple technique to achieve my goal?
In your Using block, before the line with DownloadString, set the Credentials of your WebClient:
Private Function getVersion() As String
Using client As New WebClient
client.Credentials = CredentialCache.DefaultCredentials
getVersion = client.DownloadString("https://companyname.sharepoint.com/site/library/version.txt")
End Using
End Function
The DefaultCredentials will be the credentials of the currently logged in Windows user.
See the docs on System.Net.WebClient.
I am new to vb.net and have a project that I have made my first windows service. Now I have a function that retrieves a count of transactions. I would like to call that function and put the results in a text file. I can hard code a stream to put into the text file, but whenever I call the function, the services just crashes. Not errors just dies. What am I doing wrong?
I have tried coding the function inside of the service-nope
I coded the function in a separate class-Nope! dies when I call it
Private Sub BrowserMailSender(obj As Object, e As EventArgs)
Try
FileIO.WriteToFile("service is started:" + Now + vbNewLine)
My_Count() 'service dies here
FileIO.WriteToFile("end" + vbNewLine)
Catch ex As Exception
MsgBox(ex)
End Try
the function works if I call from the main project but I would like the service to run and save the data behind the scenes.
The call to MsgBox is at the root of the problem. A Windows Service runs in a context where it does not have the ability to present a User Interface to the user. You'll have to find another way to communicate errors, such as the Event Log or a log file.
Prior to Vista, the line between services and the user was permeable, partly because the OS wasn't yet designed to keep them isolated, and partly because most users ran with full administrative privileges all the time. From Vista forward, you have to work "in the dark".
There are ways present a UI to the user, and one of the answers here briefly mentions one of them. However, I would caution you against trying to present a UI at all. The main principle of a service is that it sits in the background and does things without requiring the user to interact with it. Presenting a UI for events that the user is not aware are happening at that moment is an asymmetrical relationship. It could block your service indefinitely when a user isn't expecting to have to interact with it to allow it to continue.
I've been having a heck of a time trying to get this to work. I wrote both a service and a form application in VB.NET, both of which need to access a registry key to locate a computer that has my database on it. In the forms app it works great, but the service does not. I thought it was a permissions problem so I checked permissions on the server (Windows 2008) and they were fine - I even went as far as to run the service as the admin in case that was the problem but still no joy. Is there something wrong with my code?
I have tried ways to access the registry. The first method just sets the server variable to nothing and the second method the 'rk' variable ends up being nothing (telling me that it cannot even locate the sub key):
Dim server As String = My.Computer.Registry.GetValue("HKEY_LOCAL_MACHINE\SOFTWARE\EPS\XPV", "Server", Nothing)
and the second one is:
Dim rk As RegistryKey = Registry.LocalMachine.OpenSubKey("\SOFTWARE\EPS\XPV")
The service itself starts up just fine because I'm getting my log messages right after these lines that tell me the value is blank so it just comes down to figuring out why I cannot access the registry in the service even though I can in the forms app.
Either look under HKLM\SOFTWARE\Wow6432Node for your keys/values, or compile your application as 64bit.
I am the IT department of a Non-Profit organization. I have a question today which might be too specialized for this forum and I hope I do not waste my time writing it up. We are using Blackbaud's 'Raiser's Edge' (RE) Software (written in VB6 and VB.net as far as I know) to keep track of our membership and donations. We have an MS Access application (have been using it since before we got RE) to process donations and for now I want to keep it and only do minor changes to adapt it to the new software.
The MS Access program is now doing a few calls to the RE API which work great. To login and establish a connection I have to create a new 'REAPI' object and use it for other API calls. That REAPI object has a method called: SignOutOnTerminate which needs to be set to TRUE when creating that object. It is supposed to kill all connections to RE once my application closes. There is no regular .close method.
Once I create the object I can do work as many times as I want and there is no problem at all as far as I can see.
However when trying to close the application or set the object to nothing (Set REAPI = Nothing) Access crashes immediately (It fades out and I get the message that Windows is looking for a solution to the problem. Then Access closes and restarts itself.)
It is more annoying and unprofessional then hindering production but I want to fix it.
The App was developed on Windows 7 64-bit with Access 2010 32-bit. It was tested on Windows XP with Office 2003 or 2007 machines (32-bit) and behaves the same way.
I have posted this problem already on 2 Blackbaud forums and tried a suggested a work around which did not work (kill the process with a shell command and then set the object to nothing). Hopefully I will get more answers soon.
I tried to just exclude the SignOutOnTerminate when creating the object. But got the same behavior.
I looked in the Event Manager --> Application Log and found the Crash. It reported that access crashed because of this dll: C:\Windows\System32\MSVBVM60.dll (It is actually located in the SysWos64 folder as it is a 32-bit application).
Looking up this error I found some suggestions to replace it with an earlier version of the dll, the one which ships with XP. I found a file and tried the suggestion but it still crashed. The error log reported the older version number as faulting so I registered it correctly.
I also created a case with Blackbaud but the rep did not know what the problem is and did not have MS Access installed. He is trying to get his support team to install it for him so he can test and investigate this error.
The last suspicion I have is that the API is causing the error and my code is fine.
But before I make this assumption and until I get my answer from Blackbaud I want to do a final check, but I have run out of ideas for further trouble shooting and resorted to pose this problem in this forum.
Any Ideas?
I realise that this is an old thread and if you have solved this by now then that is great. However this is a known issue with The Raiser's Edge API. If you use .NET with RE's API (which is COM based) there is definitely some resource that is not cleaned up properly. At one point I suspected that it was something to with making use of RE's graphical interface i.e. by calling the regular login method to log you into RE. However even if you log in to RE using the "as a server" method supplying the user name and password it still crashes on exiting the application.
We have an installer that sets up credentials in RE. The installer is in .NET and accesses the RE API. We now show a message just before the end of the application telling users to ignore the impending crash... Not a great solution by any means.
I am writing a windows service that needs to be running 24/7. It is a pretty simple service that monitors a directory where files are dropped into and processes those files. I need to restart the service if an unhandled exception is thrown.
Is there a way for a service to restart itself in the event of an unhandled exception?
The Services applet has many different recovery features:
It can take different actions on the first, second, and subsequent failures:
Restart the service, after a configurable delay
Run a Program (passing command line parameters, possibly including the failure count)
Restart the Computer (after a configurable delay, and with a particular message being sent)
The program that runs should be able to look in the event log and see the reason for failure (especially if you log it), and should therefore be able to disable the service if the exception is one that is not recoverable.
And, of course, in the meantime, the service should be logging what's going on, which should enable any management tool to notify Operations of what's going on.
I agree that you should probably not configure "third and subsequent" to be "restart service", or you could wind up in a loop.
Have you tried using the Recovery tab of the Service entry - you can set rules for failures, including "Restart the Service" - by default this is on "No Action"
This is able to be done programatically if you wanted, this code was not written by me. I am posting the link to the Authors CodeProject page that contains the source / binaries. Below the link I have explained how I implemented the authors code.
http://www.codeproject.com/KB/install/sercviceinstallerext.aspx
Add a reference to the DLL.
Open ProjectInstaller.Designer.vb in notepad
In the InitializeComponent Sub
CHANGE
Me.ServiceProcessInstaller1 = New System.ServiceProcess.ServiceProcessInstaller
Me.ServiceInstaller1 = New System.ServiceProcess.ServiceInstaller
TO
Me.ServiceProcessInstaller1 = New System.ServiceProcess.ServiceProcessInstaller
Me.ServiceInstaller1 = New Verifide.ServiceUtils.ServiceInstallerEx
With the Friend Declarations in the ProjectInstaller.Designer.vb
CHANGE
Friend WithEvents ServiceProcessInstaller1 As System.ServiceProcess.ServiceProcessInstaller
Friend WithEvents ServiceInstaller1 As System.ServiceProcess.ServiceInstaller
TO
Friend WithEvents ServiceProcessInstaller1 As System.ServiceProcess.ServiceProcessInstaller
Friend WithEvents ServiceInstaller1 As Verifide.ServiceUtils.ServiceInstallerEx
CHANGE
Me.Installers.AddRange(New System.Configuration.Install.Installer() {Me.ServiceProcessInstaller1, Me.ServiceInstaller1})
TO
Me.Installers.AddRange(New System.Configuration.Install.Installer() {Me.ServiceInstaller1, Me.ServiceProcessInstaller1})
Import The Namespace On ProjectInstaller.vb
In ProjectInstaller.vb in the Public Sub New Function After Initialize component function has been called
ADD
'Set Reset Time Count - This Is 4 Days Before Count Is Reset
ServiceInstaller1.FailCountResetTime = 60 * 60 * 24 * 4
'ServiceInstaller1.FailRebootMsg = "Houston! We have a problem"
'Add Failure Actions
ServiceInstaller1.FailureActions.Add(New FailureAction(RecoverAction.Restart, 60000))
ServiceInstaller1.FailureActions.Add(New FailureAction(RecoverAction.Restart, 60000))
ServiceInstaller1.FailureActions.Add(New FailureAction(RecoverAction.None, 3000))
ServiceInstaller1.StartOnInstall = True
Build installer and install. Voila
Wrap your service code in a runner which can catch any errors and restart your service.
The best way is to wrap Try / Catch blocks around the methods in the service you can afford to let throw exceptions.
However, there may be serious exceptions thrown that should result in the service being stopped immediately. Don't ignore these! In these cases, handle the exception, log it, email it and then rethrow it. That way you will be informed that the exception has occurred and will know what went wrong. You can then fix the problem and re-start the service manually.
Just ignoring it could cause a major failure in your system which you would not know about. It could also be very expensive on CPU/RAM if the service stops then restarts then stops ad infinitum.
As suggested by "John Saunders" and "theGecko", you can monitor the service and restart it when it fails. The builtin Windows Service Recovery functionality will get you a long way, but if you find that you need some more advanced features (for example, CPU hogging and hang detection) then please check out Service Protector. It is designed to keep your important Windows Services operating 24x7.
Good luck!