RESOLVED - Suggestions to resolve Runtime Error 75 path/file access denied

Hey guys,

Need your help in solving this problem.

My program executes a function once every 2 minutes. When this happens, my code further down below writes an entry into a text file. This occurs every 2 minutes indefinitely.

Everything works fine until day 7. On the 7th day this error appears "Runtime Error 75 path/file access denied". The error occurs on this line...

Open app.path & "\Logs\Bin\" & "Log these details here.txt" For Input As #xfilenumbr

'Here's my full code

Private Sub Timer31_Timer()

Timer31.Enabled = False

Dim xfilenumbr As Integer
xfilenumbr = FreeFile

dim abc as string
dim xyz as string

dim sttr as string
sttr = WeekdayName(Weekday(Now, vbUseSystemDayOfWeek), _
False, vbUseSystemDayOfWeek)


'opens the txt file and reads all the existing entries into the list2 box
List2.Clear
Open app.path & "\Logs\Bin\" & "Log these details here.txt" For Input As #xfilenumbr
Do While Not EOF(xfilenumbr)
Line Input #xfilenumbr, xyz
List2.AddItem xyz
Loop
Close #xfilenumbr

'deletes the txt file and all of its contents from the Bin folder
abc = app.path & "\Logs\Bin\" & "Log these details here.txt"
Kill abc

'Recreates a new empty Log these details here.txt file into the Bin folder
Open app.path & "\Logs\Bin\" & "Log these details here.txt" For Output As #xfilenumbr
Close #xfilenumbr


'If the entries in the list2 box are 1000 or more, the list2 box entries are cleared and the most recent entry is added to the file.

If List2.ListCount > 1000 Then

List2.Clear
Open app.path & "\Logs\Bin\" & "Log these details here.txt" For Append As #xfilenumbr
Print #xfilenumbr, "-This process completed successfully on" & " " & sttr & "," & " " & Now & "."
Print #xfilenumbr, " "
Close #xfilenumbr

Else
'If the entries in the list2 box are less than 1000, the most recent entry is added to the top of the file and the remaining list2 box entries are then appended below that entry.

Open app.path & "\Logs\Bin\" & "Log these details here.txt" For Append As #xfilenumbr
Print #xfilenumbr, "-This process completed successfully" & " " & sttr & "," & " " & Now & "."
Print #xfilenumbr, " "

For r = 0 To List2.ListCount - 1
Print #xfilenumbr, List2.List(r)
Next
Close #xfilenumbr

List2.Clear

End If

End Sub

I'm using an admin account for my testing and all works fine for 6 days straight. I cant figure out why the code throws the error on day 7. If anyone has any insight or another method to write/read the text file, Id really appreciate the help.

Thanks,

Patrick

Error 75 path/file access denied normally means you don't have admin rights to manipulate files in that folder.

Open app.path & "\Logs\Bin\" & "Log these details here.txt" For Input As #xfilenumbr

You have this line three times in your code. If your using FreeFile then show it else it will use the same number each time. ;)

xfilenumbr = FreeFile()

each time you using it.

That doesn't seem to be a copy of your actual code since things like dim aren't capitalized. Can you show us your actual code?

How are you handling errors?

The 'access denied' isn't always related to permissions. Its possible you already have the file open or locked.
Perhaps something caused an error 2 minutes ago and left the method before calling Close#. Then when you come back in, 2 minutes later, the file is already open.
Because it is consistantly 7 days, maybe the ACTUAL error is with some date handling/parsing. Is it always 7 days, or is the 7th day always Sunday (or Friday or whatever)
And yes, as Keith suggested, make sure you reset your fileNumber everytime you use it. That could be related to your problem, but that would be very strange that it's every 7 days.


Annnnnnnd... a final thought... to test whether the error is due to process or if it's related to dates... start your program, then set your system date to 7 days later (6 6and 23 hours, or whatever would trigger the problem) Then you have some control on when the problem should fire. If it fires just because you changed the date, I'd check out those functions. (They look right to me, but maybe Im missing something)

does the file get to a specific size every 7 days?

can you open the file from someother vb code /app?
can you open the file in any other application?

Hey Guys,

Thanks for replying.

Keith,

I figured since I was using the Close #xfilenumbr statement, the file number in use would clear each time and then I could reuse it. How do I reset the file number?

MartinLiss,

You're right. per your prompt, please see below...

Golgo1,

I'm not handling errors for this code yet. In the past, I was thinking of adding the On Error GoTo errHandler statement and then use the file Close #xfilenumbr statement but I was hoping to resolve the problem and then use error handling to catch any other errors that may occur which would at least keep the program running.

yes, the file open/lock scenario did cross my mind. So, I tried a static number ie: For Input As #1, close #1 etc. but the problem still happens.

as for as the 7 day situation. The error occurs on the 7th day from program startup. so it can occur on any day of the week. It also occurs at diffferent hours on the 7th day.

Pete,

I would have to test out and come back with the results. Which I'll definitely do but was hoping to try a possible fix first.

Code:

---

Private Sub Timer31_Timer()

Timer31.Enabled = False

Dim xfilenumbr As Integer
xfilenumbr = FreeFile

Dim abc As String
Dim xyz As String

Dim spath As String
spath = App.Path

Dim sttr As String
sttr = WeekdayName(Weekday(Now, vbUseSystemDayOfWeek), _
False, vbUseSystemDayOfWeek)

List2.Clear
Open spath & "\Logs\Bin\" & "POP3 Connection Log.txt" For Input As #xfilenumbr
Do While Not EOF(xfilenumbr)
Line Input #xfilenumbr, xyz
List2.AddItem xyz
Loop
Close #xfilenumbr

abc = spath & "\Logs\Bin\" & "POP3 Connection Log.txt"
Kill abc

Open spath & "\Logs\Bin\" & "POP3 Connection Log.txt" For Output As #xfilenumbr
Close #xfilenumbr

       
If List2.ListCount > 1000 Then

List2.Clear
Open spath & "\Logs\Bin\" & "POP3 Connection Log.txt" For Append As #xfilenumbr
Print #xfilenumbr, "-This POP3/Single PC mode computer successfully logged into the remote POP3 email account on" & " " & sttr & "," & " " & Now & "."
Print #xfilenumbr, " "
Close #xfilenumbr

Else

Open spath & "\Logs\Bin\" & "POP3 Connection Log.txt" For Append As #xfilenumbr
Print #xfilenumbr, "-This POP3/Single PC mode computer successfully logged into the remote POP3 email account on" & " " & sttr & "," & " " & Now & "."
Print #xfilenumbr, " "

For r = 0 To List2.ListCount - 1
Print #xfilenumbr, List2.List(r)
Next
Close #xfilenumbr

List2.Clear

End If

spath = vbNullString
sttr = vbNullString

abc = vbNullString
xyz = vbNullString

End Sub

---

please use code or highlight tags to display code
how big does your file get by the 7th day?

i seem to remember from somewhere, any open files are implicitly closed at the end of a procedure
close without filenumber will close all

Pete,

got it.

Im not sure on the file size as I'll need to re-run the program again for a full 7 days.

Thanks for the Close approach. I now have that working at the bottom of the sub





Patrick

I added Code tags around your code that you posted above but since you don't use indenting it doesn't help much. Here is how most people would format your code to make it easier to read.

Code:

---

Private Sub Timer31_Timer()

Timer31.Enabled = False

Dim xfilenumbr As Integer
xfilenumbr = FreeFile

Dim abc As String
Dim xyz As String

Dim spath As String
spath = App.Path

Dim sttr As String
sttr = WeekdayName(Weekday(Now, vbUseSystemDayOfWeek), _
False, vbUseSystemDayOfWeek)

List2.Clear
Open spath & "\Logs\Bin\" & "POP3 Connection Log.txt" For Input As #xfilenumbr
Do While Not EOF(xfilenumbr)
    Line Input #xfilenumbr, xyz
    List2.AddItem xyz
Loop
Close #xfilenumbr

abc = spath & "\Logs\Bin\" & "POP3 Connection Log.txt"
Kill abc

Open spath & "\Logs\Bin\" & "POP3 Connection Log.txt" For Output As #xfilenumbr
Close #xfilenumbr

       
If List2.ListCount > 1000 Then

    List2.Clear
    Open spath & "\Logs\Bin\" & "POP3 Connection Log.txt" For Append As #xfilenumbr
    Print #xfilenumbr, "-This POP3/Single PC mode computer successfully logged into the remote POP3 email account on" & " " & sttr & "," & " " & Now & "."
    Print #xfilenumbr, " "
    Close #xfilenumbr

Else

    Open spath & "\Logs\Bin\" & "POP3 Connection Log.txt" For Append As #xfilenumbr
    Print #xfilenumbr, "-This POP3/Single PC mode computer successfully logged into the remote POP3 email account on" & " " & sttr & "," & " " & Now & "."
    Print #xfilenumbr, " "

    For r = 0 To List2.ListCount - 1
        Print #xfilenumbr, List2.List(r)
    Next
    Close #xfilenumbr
   
    List2.Clear

End If

End Sub

---

I left out the setting of the string variables to vbNullString as VB initializes local variables each time the sub is run so you doing it is totally unnecessary.

BTW how often is that timer run?

Quote:

---

Originally Posted by techsent

Keith,

I figured since I was using the Close #xfilenumbr statement, the file number in use would clear each time and then I could reuse it. How do I reset the file number?

---

Just set it again before you use it.

xfilenumbr = FreeFile()

There maybe another part of your program thats using xfilenumbr that you're forgotten about. As stated just using just the Close statement will close all files your app has open.

But it still comes down to the original question. An Error 75 means you don't have admin rights to deal with files in that folder.

I'm not sure what this 7 days bit means? Are you trying to open and change these files on different days? ;)

I believe what he is saying is that once the program is started that it runs constantly and that for example if he starts it on a Monday it fails the next Monday, or if he starts it on a Wednesday that it fails the next Wednesday, etc.

techsent: Could you zip up and attach your whole project please?

Thanks MartinLiss. Yes, it runs every 2 min 8 sec.

Right on Keith. I have it in there now.

Attached is the project. Go through the Readme.txt file to get it up and running.

Patrick

I haven't run your program but I've noticed several things.

1) There's no need to have 3 timers just so you can have a 2 min 8 sec interval. Just use one timer with an interval of 32 seconds and do this instead.

Code:

---

Private Sub Timer1_Timer()
Static intCount As Integer

intCount = intCount + 1

If intCount = 4 Then
    ' Do your processing or call a sub. The Interval for this timer is 32000 (32 seconds)
    ' so your code will run every 2 Min 8 seconds (4 x 32 seconds)
    Debug.Print Now
    ' Restart the count
    intCount = 0
End If

End Sub

---

2) Variables like sttr defined globally at the top of the form should be defined using Private rather than Dim. That's just a matter of style but Private is the more "modern" way of doing things. More important however is that you also have an sttr defined locally in Timer31_Timer and that's not a good thing to do since any reference to sttr in that sub refers only to the sttr in that sub and not the global one and you (or someone else maintaining your code) may not realize that.

3) As I mengtioned in a previous post, variables don't need to be initialized at the end of subs. VB will do that for you the next time the sub is run.

4) You have a sub that looks like this:

Code:

---

Private Sub Winsock1_Close()

On Error GoTo errHandler

username = vbNullString
password = vbNullString


Exit Sub

errHandler:

username = vbNullString
password = vbNullString

spath = App.Path
sttr = WeekdayName(Weekday(Now, vbUseSystemDayOfWeek), _
                    False, vbUseSystemDayOfWeek)
                   
Dim hFile As Integer
hFile = FreeFile()
                   
List2.Clear
Close #hFile
' and a lot more code

---

There's no reason to have an error handler in that sub because there's no way that setting username and password to vbNullString is going to cause an error, and even if it did you have the same code in the error handler which would be a problem if setting those variables to vbNullString did cause an error.

(I've got more to say but I'm going to post this now since my computer is acting up.)

4) You don't need spath, just use App.Path directly. You could however do something like Private sErrorLogPath As String and Private sConnectionPath As String at the top of the form and then in Form_Load do sErrorLogPath = App.Path & & "\Logs\Bin\POP3 Error Log.txt" and sConnectionPath = App.Path & & "\Logs\Bin\POP3 Connection Log.txt" and then every other place you want to open one of those files just do for example Open sErrorLogPath For Input As #xfilenumbr.

Hey Martin,

Thanks for your guidance on this. I've implemented all of your corrections.

I variated a bit on the timer1 code because I think timer31 should only fire when the login was successful. So the timer1 code fires the login sequence only.

re: vbnullstring, about 3 months ago, I was getting really frustrated with the winsock data arrival event because after 4 days of continuously running I would get the 10055 Out of buffer space error.
So I ended up changing the Dim statements in that event to Static and then added the vbnullstring to all the strings in the project thinking I wasn't clearing the string variables thus the error would occur.
Based on your prompt, Im thinking the Static change made the difference because the error no longer appears. Then I thought I was home free til the error 75 problem.

I've started the program about 15 min ago for the new test, so I'll report back next Sunday if the error appears or Monday on the 8th day.

Again, I appreciate everyones help.

Thanks,

Patrick

Hey guys,

Here's the status...

On saturday (day 6), an error 53 file not found message appeared. I checked the Bin folder and both files were still present. The POP3 connection log.txt files was 51kb in size.

Unfortunately, I didn't run the test in VB so I don't know what line of code generated the error.

Based on the error message and that the file is still present, Im guessing that it may the Close statement so I removed it. Also for the freefile () entry, I added a rangenumber thinking that it may help. ie: freefile (50).

Now, I running a new test (inside of VB this time). I'll report back again in a week.

Thanks,

Patrick

The Close statement closes all files so unless you inadverently closed a file that you needed to be open, it probably isn't that. FreeFile generates an (unused) integer so unless you had 32767 files open, which of course is unlikely, it's probably not that either.

I just checked and the FreeFile limit is a lot smaller than I thought. If you try to open more that 255 files, FreeFile will generate error 67.

Hi Martin,

Thanks for replying and your info.

Yes, I'm not too confident about my changes. I figured the freefile () and Close statements aren't the problem. changing code and hoping just doesn't replace the methodical/logical approach.

Admittedly, I've been working on my main project for over 2 years now and the problem in this thread is the last hurdle. As a result, Ive been fighting a loss of enthusiasm and frustration for quite awhile now.

I was thinking of trying to use the Binary Lock Read Write As #nFileNum method instead of what I have. What do you think?

Techsent

Sorry but I have no idea if Binary Lock Read Write would affect anything.

Could you attach your project again please?

did you try any of the suggestions i made in post #5?

when the error occurs, copy the file to someother location
make a simple program in vb to open the file, also the copy file, see if either will work
try opening the file in word, notepad or some application

i doubt that it was a problem with your code, even the original version

can you start a new file every 6 days so that it never gets to the point of error?

Hi Martin,

I would really like to attach my main project but I plan on selling the compiled exe's so unfortunately, I can't broadcast my code to the public. I know it's a catch 22 because its tough to assist someone when you don't have the whole project to look through.

Pete,

I didn't but I definitely will this time. Im on day 3 so I'll have the answers in a few more days.

Thanks,

Patrick

I am not sure what your updated code but when you are closing the filenumber then before you use it again it is better to still get the FreeFile.

Code:

---

xFileNumbr = FreeFile
    Open sPath & "\Logs\Bin\" & "POP3 Connection Log.txt" For Output As #xFileNumbr
    Close #xFileNumbr

---

And so on.

Quote:

---

Originally Posted by dee-u

I am not sure what your updated code but when you are closing the filenumber then before you use it again it is better to still get the FreeFile.

Code:

---

xFileNumbr = FreeFile
    Open sPath & "\Logs\Bin\" & "POP3 Connection Log.txt" For Output As #xFileNumbr
    Close #xFileNumbr

---

And so on.

---

Yes I've mensioned this before Dee. ;)

Guys,

okay, day 6, The error 53 file not found message appeared again and was generated on the bolded line.

Code:

---

abc = sConnectionPath
Kill abc

---

I spoke with Martin and the abc string value was removed and the code is now modified like this...

Code:

---

Kill sConnectionPath

---

I also added the Close statement back in and left the freefile (50) as is.

Ive just started a new test.

Pete,

"when the error occurs, copy the file to some other location make a simple program in vb to open the file, also the copy file, see if either will work try opening the file in word, notepad or some application."

I was able to open the file using another vb app and also within notepad with no problems.

"can you start a new file every 6 days so that it never gets to the point of error?"

great idea and I'll definitely implement it as a workaround.

Techsent

Any problem with me attaching a modifed Form1 from the POP3 Connect folder? I made a number of changes all of which are marked with 'Marty so you can find them easily.

I also added some questions and comments in the code. In addition to those I strongly suggest you use meaningful names for your forms and controls rather
the default Form1, Combo1, etc names. When you name global or form level variables you should also name them for example mintCurrentMessage rather
than intCurrentMessage (they should also be Private rather than Dim) to indicate that it's a form-level variable and if you had global variables
(which would be Public rather than Dim) in one of your code modules they should be prefixed with a g, so gMyVar rather than MyVar. I am also curious
why you need 16 timers in the server portion of the app.

I've been watching this thread for some time and thought I may be able to make a contribution...

I think that the Winsock 10055 error may be the root of the problem. It is indicative of a lack of system resources. When associated with a long running application such as yours it may mean that you are not releasing memory and you're eventually starving the application. Alternatively the application may be leaking memory and after 6 days you've 'run out'. The result of this may be an almost 'random' error such as the one you're experiencing (after all, you do have access to the file, so the error message may be / is misleading you)

Making the change you did to 'resolve' the 10055 error has, perhaps, just allowed the problem to manifest itself somewhere else.

Trying to find what's eating up memory is not easy. If my theory is right you should see a steady increase in Working Set size during the running of the application, although if it's associated with the Winsock Buffers you may not see it, as the internal buffers use non-paged memory. It may be worth using Task Manager to monitor it.

I noticed some other 'issues' with the code you posted:
In the DataArrival event:

Code:

---

Static strData1            As String
Winsock1.GetData strData1, vbByte

---

vbByte should be vbString.

and there's an 'orphan' Close statement in the DataArrival event:

Code:

---

For r = 0 To List2.ListCount - 1
 Print #hFile, List2.List(r)
 Next
Close #hFile
Close

---

Also, I see some DoEvents which are not needed. If you want to make sure that the "QUIT" command has been sent before you close the Socket you should use the SendComplete event to signal rather than rely on DoEvents. If I was being really picky I'd point out that DoEvents is a Function which returns an Integer value (the number of currently open Forms in the Application)

Code:

---

Dim intF As Integer
.
.
intF = DoEvents
.

---

but I think I'm going over the top on that !!!

Saying all that, I doubt if any of those issues are causing the problem but with memory issues which manifest themselves after 6 days it could be something quite trivial.

Have you reduced the number of Timers as Martin has suggested? I think life would be made a lot easier if you reduced the number of asynchronous events to a minimum to avoid the possibility of "events-within-events" which can cause unpredictable results.

No problem, That would be great. Thanks for the info on Dim etc..., I'll action on my end.

Yes, I do use alot of timers :o. I mainly use them as events. Once a specific action has occurred in the app, the timers turn on then turn off again. I figured since the timer intervals usually start a few seconds after the specific action has occurred/completed in the app, it would be ok.

Timer8_Timer() runs continuously because it's checking the registry for the newest data to send to the network clients. Once the data is detected, the timer event also broadcasts the data to those connected clients.

Hey Doogle,

Thanks for chiming in. I've reverted vbByte back to vbString. I had previously changed it to byte thinking it may have been part of the 10055 error. That 10055 error has been tough. I worked on that problem for a couple of months and finally the latest code worked for 17 days straight before I ended the test. The error would always appear after running it for 3 days.

Yes, the orphaned Close entry was added to ensure that all open file numbers were closing.

Your memory comments sounds like a definite possibility. I have monitored taskman in the past and while the working set value does rise via pop3 login it appears to drop off and remain steady until the next login.

The Timers that Martin mentioned are in another sub project which isn't used for the testing of the attached project in this thread. Please see my comments above.

I appreciate the DoEvents details. Here's my modification.

Code:

---

Private Sub Winsock1_DataArrival(ByVal bytesTotal As Long)

SaveSettingString HKEY_CURRENT_USER, "Software\System Pitstop", _
      "quitwinsock", _
        "1"
                   
m_State = POP3_QUIT
Winsock1.SendData "QUIT" & vbCrLf
'DoEvents
'moved to Winsock1_SendComplete()
'winsock1.close

---

Code:

---

Private Sub Winsock1_SendComplete()

Dim hhg As String
hhg = getstring(HKEY_CURRENT_USER, "software\System Pitstop", _
        "quitwinsock")

If hhg = "1" Then

  SaveSettingString HKEY_CURRENT_USER, "Software\System Pitstop", _
      "quitwinsock", _
        "0"
       
  Winsock1.Close

Else

  SaveSettingString HKEY_CURRENT_USER, "Software\System Pitstop", _
      "quitwinsock", _
        "0"

End If

End Sub

---

Talking of DoEvents, I had a peculiar encounter a couple of years ago on Vista. This piece of info might or might not have a direct relevance to your current case, given here just for your longshot reference.

In my viewport user control, I had something like this:

PicDisp_MouseDown
.....
Action1
Action2
.....

For a certain reason, I had to add a DoEvents between Action1 and Action2. Now the system would execute PicDisp_MouseUp before coming back to execute Action2 of PicDisp_MouseDown. (It took me a long time to discover that, but once discovered, a solution was easy). This phenomenon didn't always appear; I now can't recall whether it was depending on how quick the user's mouse action or how long the Action2 took.

Remarks: The specific reason for adding a DoEvents was to enable user to drag (to scroll) picDisp in the viewport on a non-active child form immediately on its becoming active, e.g. there were several child forms on MDI screen and picDisp in the viewport on each form was visible to the user, the user might thus mouse down on any picDisp (to scroll) while making that form active. (Without the said DoEvents, the user would have to click to set focus to that form first, then mouse down to scroll picDisp).

Here it is.

Thanks Martin,

Here's the latest update.

*A new test has now been started with this attachment.

petersen,

Yes, I also found that certain situations where the DoEvents helped. I think whether it helps or creates conflicts may depend on what code it's preceded or appended too.

Techsent

I think you're missing the point of my comment about your hhh variable. The way your code is now your obr9f, a, i, j, and k variables will never contain anything because you fill hhh and then immediately set it to vbNullString. If you don't set it to vbNullString the variables willl all contain the same value. The following is some code that shows both cases. Paste it into a new project and try it.

Code:

---

Dim hhh As String
Dim obr9f As String
Dim obr9a As String
Dim obr9i As String
Dim obr9j As String
Dim obr9k As String

hhh = "fullscan"

hhh = vbNullString

obr9f = Mid(hhh, InStr(hhh, " ") + 1)
obr9a = Mid(hhh, InStr(hhh, " ") + 1)
obr9i = Mid(hhh, InStr(hhh, " ") + 1)
obr9j = Mid(hhh, InStr(hhh, " ") + 1)
obr9k = Mid(hhh, InStr(hhh, " ") + 1)

MsgBox obr9f
MsgBox obr9a
MsgBox obr9i
MsgBox obr9j
MsgBox obr9k

'do it again without the vbNullstring line

hhh = "fullscan"

obr9f = Mid(hhh, InStr(hhh, " ") + 1)
obr9a = Mid(hhh, InStr(hhh, " ") + 1)
obr9i = Mid(hhh, InStr(hhh, " ") + 1)
obr9j = Mid(hhh, InStr(hhh, " ") + 1)
obr9k = Mid(hhh, InStr(hhh, " ") + 1)

MsgBox obr9f
MsgBox obr9a
MsgBox obr9i
MsgBox obr9j
MsgBox obr9k

---

Regarding this code:

Code:

---

Open sErrorLogPath For Output As #hFile
Close #hFile
       
If List2.ListCount > 1000 Then

    List2.Clear
   
    Close #hFile
    hFile = FreeFile
   
    Open sErrorLogPath For Append As #hFile

---

You don't need to open and immediately close the file in order to create/ set up the file on the hard drive for the list count. Just do the Open sErrorLogPath For Append As #hFile when you need it. VB will create the file if it's not already there even though you specified Append.

Hey Martin,

sorry about that. The hhh variable will not be empty once the keyword is processed from the pop3 email. The code spins through all the emails in the inbox. Once it finds the keyword, the hhh will then contain the keyword.

If you run the whole project, it will give a demo.

Thanks. I've changed up the code to use append only.

Techsent

Quote:

---

Originally Posted by techsent

Hey Martin,

sorry about that. The hhh variable will not be empty once the keyword is processed from the pop3 email. The code spins through all the emails in the inbox. Once it finds the keyword, the hhh will then contain the keyword.

If you run the whole project, it will give a demo.

Thanks. I've changed up the code to use append only.

Techsent

---

Yes, it will, because you set it to vbNullString immediately after it is filled. And even if that is not the case, all the obr9 variables that I mentioned will have the same thing in them. Is that what you want?

I see what you're saying. when I originally created the main project, I copied the obr9 variables from it into the pop3 connect.

I could have used 1 variable and passed it to main (timer44, timer43).

Techsent

Do you agree about both things I'm saying?

I do indeed.

Techsent

Me again, nothing important to add at this time, but whilst we're eagerly awaiting the latest test results..........

I notice that you do not process the result of sending POP3_DELE. Also there's a couple of DoEvents in parseMSG, I don't think they're doing any harm as parseMSG is not interrupt driven.

Strictly speaking, in the DataArrival event you should not assume you have a complete response from the server when you issue the GetData. You are employing buffering on the RETR but not on any other response. The responses from POP3 are quite short so it's unlikely that they will split into two or more parts, however it is possible which could lead you to report errors when there weren't any, or the application exploding when you try to unblock the count of messages into AmtMessages. (I have, in the past, experienced a 10 byte message being split into two 'parts' by the underlying protocols. ie it took 2 DataArrival events for the complete 10 byte message to arrive)

I would append the data received into strData1 until a carriage return line feed pair had been received and then check for the "+". It's only at that point you know for sure you have a complete response from the server. If you do that you have to clear strData1 after processing the contents.

Perhaps things to put on your "To Do" list after the current problems are resolved.

I'm still worried about the number of Timers and the fact that you have more than one running at the same time.

This next part may be 'off the wall' but I'm still thinking about whether it's possible or not so don't take it too seriously .....

I'm wondering about the accuracy of the Timer control which I believe is about +/- 57mS. In the extreme, if, say, Timer3 is always triggering 'early' then I estimate that after 6 days it would be nearly 4 minutes out - I can't see if and where you stop Timer3. (After 6 days the Timer3 code proper has executed about 4050 times - interesting that it's not too far away from 4096, I wonder if there's a 4K limit to something in VB) If the other timer is running 'late', one may catch the other up.....

As I said, 'off the wall', could be absolute nonsense, but I'm still trying to get my head round it.

Is there any reason why you can't just start a timer, when 2 minutes, or whatever, have elapsed, stop the timer, execute the 'business' code, re-start the timer and go round the loop? That way any inaccuracy of the timer doesn't matter since there's only ever a maximum of 1 timed asynchronous event. You will also process the complete message queue in one hit. (At the moment you have a maximum of 2 minutes to process the queue then you close the socket whether you've finished or not)

Another 'off the wall' thought, if there's some sort of 'issue' with Winsock getting its buffers in a twist, I wonder whether using a dynamic Winsock instance and Unloading it when you've closed it (which should destroy it completely, freeing up internal buffers etc), then Loading a new instance before configuring it for connection, would eliminate any problems. You'd be starting with 'a clean sheet' (wrt Winsock) every time you connected to the server.

eg Define Winsock1 as an array, Load Winsock1(1), use Winsock1(1), Unload Winsock1(1) when you've finished, and repeat.

EDIT: By the way, don't know if it's been asked already but have you got VB SP6 installed? Amongst other things, that SP fixed a few Winsock issues including leaking memory.

The problem with this problem is that you will never know if it's fixed and if it is, how you did it !!! (LOL)

Hey Doogle,

Yes, I decided to not log the POP3_DELE result as its been extremely reliable.

I had to add the DoEvents because the email flagged for deletion wasn't getting deleted after logging out and back in.

Good point on the DataArrival event. I discovered that before using the msgbox command. It would hit many times in one session.

the timer computation conflict is interesting. I'll check into it.

I've been trying to implement your technique Load Winsock1(1), Unload Winsock1(1) but need some guidance. I have set the index properties of winsock1 to 0. Added (Index As Integer) to all winsock code headings. Next, I configed this.

Code:

---

Option Explicit

Public intwinsck As Integer

End Sub

---

During run time, the error hits and displays - error 360 object already loaded.

Code:

---

Private Sub Form_Load()

intwinsck = 0

Load Winsock1(intwinsck)

End Sub

---

Code:

---

Private Sub Timer3_Timer()

m_State = POP3_Connect

'Winsock1(intwinsck).Close
Winsock1(intwinsck).LocalPort = 0
Winsock1(intwinsck).Connect tstring, kevo

End Sub

---

When trying to unload winsock1, I get error 362 - can't unload controls created at design time. I tried the exe but same error.

Code:

---

Private Sub Timer31_Timer()

Unload Winsock1(intwinsck)
End Sub

---

Yes, thanks, I have sp6 installed.

LOL, yes, I was thinking that after implementing everyones suggestions.

Techsent

If at design-time you have Windsock(0) then you cannot load or unload it at runtime, you can just load and unload succeeding indexes eg. 1, 2, 3, etc.

Thanks Dee-u and Doogle! I was thinking the Load statement would auto increment upon execution. Plus, I had some Close statements in the project which wern't working.

I think I've got it figured out....

Techsent

Hey guys,

alright, day 5 and the Socket Error 10055 - No buffer space is available appeared.

It occurred on the bolded line below...

Code:

---

Private Sub Timer3_Timer()

m_State = POP3_Connect

Winsock1(intwinsck).Close
Winsock1(intwinsck).LocalPort = 0
Winsock1(intwinsck).Connect tstring, kevo

    intCount = 0

End Sub

---

Im thinking since it's on the .Connect line, tcpip ran out of buffers on the last login. So the next login attempt generated the error.

I just started a new test with Doogle's Load Winsock (1), Unload Winsock (1) method. *please see the most recent attachment above this post.

Thanks,

Techsent

There are instances when you are unloading the control but does not close it, why is that?

Hi Dee-u,

Yes, I figured that using the Unload method would also close the socket when winsock unloaded.

I do have the Close code setup in the SendComplete event.

In addition to the above concern, Im also facing the challenge of properly Unloading Winsock. What happens is the the Unload method is invoked but the next time the Load method is invoked, error 360 appears (object already loaded). If I add the Doevents statement for testing purposes, it works fine for 10 minutes or so but then the error occurs again.

The above only happens on win xp with sp3 and doesn't happen on Vista Home Premium.

Im not sure if this is important but Im not resetting the integer of 1 back to 0 and then to 1 again. Im just letting 1 be re-used the next time winsock is loaded.

Please see the latest attachment for where Im at. Any additional help from yourself or anyone else would be great.

Thanks,

Patrick

I cannot follow what your program is doing but it looks like you are just loading one instance of a winsock, is that right? What is your purpose with that? The index is never increased so why not just use the original one?

dee-u: The idea came from a suggestion of mine in an earlier post. There is a 'funny' problem which manifests itself after the application has been running fine for days at a time. At one point the application was failing due to a reported Winsock buffer shortage and it migrated to the Runtime Error 75 at a later date following some changes to the code. My suspicion is that the root problem is still with Winsock.

The idea of using a dynamic Winsock instance was to ensure that all the Winsock resources were released after each process (a 'process' is triggered through a circa 2 minute timer) by unloading the control.

techsent: I think you will have to be careful where and when you unload the control. I suspect that trying to unload it within a Winsock event (eg Close) will not always have the desired effect.

Whilst it may seem counter intuitive I think you should close the Socket at the end of a 'process' and unload it when the Timer triggers to start the next 'process'. The Close method is asynchronous and will take a finite time to complete whilst your program is still running. You could get to a situation where you are attempting to unload the control whilst it is stil closing.

The 2 minute time delay between issuing the Close and the Unload will be long enough to ensure that the Socket has closed in a graceful manner. As a 'backstop' you could even check that it is closed before attempting to Unload it.

Something like this at the start of the Timer event

Code:

---

Dim intF as Integer
If Winsock(1).State <> sckClosed Then
    Winsock(1).Close
    Do Until Winsock(1).State = sckClosed
        intF = DoEvents
    Loop
End If
Unload Winsock(1)

---

(I know I banged on about DoEvents earlier but I think its use here is safe and valid since the Timer is the only asynchronous event running and the DoEvents will not cause the Timer or anything else to be triggered again.)

The above will check the socket is closed and if it isn't will close it. Note that if the Socket isn't closed the Winsock(1).Close event will trigger so you should make sure that there's nothing in that event related to the Socket itself.

Later on in the Timer event, before you set the Winsock properties

Code:

---

Load Winsock(1)

---

If you follow this approach you'll also have to add a Load Winsock(1) in the Form_Load event so there's one to be unloaded on the first triggering of the Timer.
(Obviously I've used 'Winsock(1)' purely as an example)

I'm still of the opinion that the Process Control can be simplified and all this problem circumvention is not really required - I think I'll have a go, if no one minds, once I've indented your code to make it a little more readable (for me at least)

Here, I reformatted the last version for anyone who is interested to fiddle with it.

Quote:

---

Originally Posted by dee-u

Here, I reformatted the last version for anyone who is interested to fiddle with it.

---

Hey dee, it seems like you are trying to help, but before confusing people in the post it would probably be a good idea to read through the whole post instead of making assumptions. The case is that the file descriptor is just not being cleared up correctly, after days of the program running stable on two computers (both are very short on RAM, and the one that gives the error most frequently is lowest on RAM out of the two). The only thing I can think of is the socket receiving the data from the other end, but leaving small bits of trash in the buffer.. which builds up, this is what Doogle has explained already.

Furthermore, you should not take the source and touch it up for redistribution in the thread yourself. Techsent should be the only one submitting sources of his program, and receiving his help or revisions privately. This man has worked very hard on SP for a long time. I am not him, and I certainly don't have the authority to judge, but when it comes to this please, remember that making 3-4 posts of quick responses isn't going to do anything, especially when you overlook most of the thread.

But, thanks for your efforts anyways. :)

PS - Doogle and the admin/moderator helping, thank you for it as well.

Quote:

---

Originally Posted by kevr

Hey dee, it seems like you are trying to help, but before confusing people in the post it would probably be a good idea to read through the whole post instead of making assumptions. The case is that the file descriptor is just not being cleared up correctly, after days of the program running stable on two computers (both are very short on RAM, and the one that gives the error most frequently is lowest on RAM out of the two). The only thing I can think of is the socket receiving the data from the other end, but leaving small bits of trash in the buffer.. which builds up, this is what Doogle has explained already.

Furthermore, you should not take the source and touch it up for redistribution in the thread yourself. Techsent should be the only one submitting sources of his program, and receiving his help or revisions privately. This man has worked very hard on SP for a long time. I am not him, and I certainly don't have the authority to judge, but when it comes to this please, remember that making 3-4 posts of quick responses isn't going to do anything, especially when you overlook most of the thread.

But, thanks for your efforts anyways. :)

PS - Doogle and the admin/moderator helping, thank you for it as well.

---

I am lazy to read through all the posts but tried to see what is in the latest version and is offering some constructive criticism, sorry about that if that confuses others. =) I merely automatically indented the code for easier reading for other members who would want to take a look, Doogle himself wants it indented before looking so I did it.

Thank you Doogle!

The attached project includes the updates.

Dee-u,

appreciate your efforts!

Kevr,

Thanks for your input. You sound like my son. Great guy he is!!! :)

Im at work now so I haven't started the attached on XP yet but will in a few hours from now.

Attached is the latest update and fully usable project. Please go through the Readme.txt file to get it up and running.

Techsent

In the DataArrival event and in the other places you are trying to read a file or delete a file you should check first if it is existing like:

Code:

---

If Len(Dir$(sErrorLogPath)) > 0 Then
    Open sErrorLogPath For Input As #hFile

    Do While Not EOF(hFile)

        Line Input #hFile, xx
        List2.AddItem xx

    Loop

    Close #hFile
End If

---

Another thing, I am not sure if this happens on the other email providers but when I am testing it with gmx it is deleting the messages in my Inbox, is this by design or perhaps I am just missing some setting in gmx?

Hey Dee-u,

Great approach on the file check code. I'll add it into the next update.

Awhile back I was also using gmx for testing. This code should only delete emails if the subject line contains the keyword. In the latest update above, I used syspit as an example keyword.

I'll sign up for a new gmx email account and check into your discovery.

I just started the latest attachment on xp.

thanks,

Techsent

Hey Dee-u,

I tested out on my end with the gmx discovery but was unable to reproduce the problem.

Please reply with the entire Subject: line contents of each email that was deleted and I'll continue testing.

Thanks,

Techsent

I sent a test message from my gmail to gmx using Test as the subject and the message itself and it was deleted everytime I run your code, winsock was reporting about this logging in failure but when I put breakpoints in the code it was hitting them. Did you use port 110 also?

Hey Dee-u,

I duplicated your efforts but the Test email remained in the inbox. What's interesting though is that the Test email subject line doesn't display in the pop3 connect listbox upon email retrieval. The other emails subject lines do.

Yes, I was also experiencing the failed login issue as well. It occured immediately after signing up for an account but the next day I was able to login ok. Yes, I use port 110.

Before I release this program to the public, I'll contact the gmx admin to discuss your findings as the problem doesn't occur with aol or my domain email server. Also, the problem may be with the parsemsg sub code as well.

Status update on the running test = 2 days and 4.5 hours with no errors! I'll status again in a couple more days.

Doogle, once again, thank you for helping me. I don't want to jump the gun, but I feel that your code is a logical implementation along with everyone else's suggested fixes.

Techsent

Okay, things are starting too look real good. 6 Days 8 min and counting...

Techsent

Don't speak too soon....... :)

so true, so true. :)

Yeah, I spoke too soon :(

at 6 days 9 hours earlier today the 10055 out of buffer space error appeared again.

Doogle, I started thinking about your comments in an earlier post where the internal buffers could be the problem.

I ran some searches on the net and came up with this statement from Microsoft:

"This behavior can occur because computers that run Microsoft Windows NT clients and use excessive numbers of ports (more than 3,976 simultaneously) may run out of ports before TCP/IP releases closed connections. The TCP/IP-state computer dictates that when a connection is closed, the connection is not released until two maximum segment lives (MSLs) have passed. This state is defined as the Time-wait state. Since one MSL is defined as 120 seconds, it takes four minutes for a closed connection to be released in TCP/IP. "

Since it takes 4 min to actually close the connection and the pop3 connect fires every 2 min, the buffers may be getting filled up and not released in time for the next connect.

In this article http://support.microsoft.com/default...b;EN-US;149532, it prompts to change the TcpTimedWaitDelay state from the default of 2 min to something lower like maybe 30 sec.

Another option may be to code pop3 connect to only connect once every 5 min (which I can certainly live with if it resolves this issue). This would then give enough time for windows to naturally close its connection thus clearing the Time_Wait state.

What do you think?

Patrick

I was aware of the issue with re-using Ports but have only come upon problems when the LocalPort is not set to Zero, I believe you're setting it to zero before opening the connection. When it's set to zero, TCP allocates a free port number to use. What I'm not clear on is whether the internal Buffers are destroyed before or after the Time-Wait, if the former then you could have some lying around.

I'm pretty sure it's a timing issue of some sort, if you opted to a 5 minute delay I suggest you start the 5 minute timer after you've processed all the data rather than let the timer run whilst the data is being processed - just in case it takes a minute or two to actually perform the pocess (eg big e-mail)