You might be looking in the wrong place for the error. When you change the Text property of a ComboBox, the ComboBox's Change event will fire, if the new text is different from the previous text. The LostFocus and/or Validate events might also fire, depending on what your code is doing and how your form is set up.
If an error occurs in the Change event handler (or in the LostFocus or Validate event handlers, if you are doing anything with them), the error-handling code in the code that changes the combobox text will never get called (this has to do with how error-handling and events work in VB6).
As a general rule, you should always put an error handler in every single routine (Sub, Function, or Property) in your VB6 code, because you can never be sure you are going to catch every error otherwise.
Here is a quick example that demonstrates that error-handling might not always work as you might think it should in VB6.
Create a new Standard EXE project and add a CommandButton (Command1) and a ComboBox (Combo1) to the default form, and add the following code to the form:
Private Sub Combo1_Change()
Dim a As Long
a = 1/0 '<-- this will cause a divide-by-zero runtime error'
End Sub
Private Sub Command1_Click()
On Error GoTo MyErrorHandler
'Change the combobox text.'
'This will cause the Change event to fire'
Combo1.Text = "test"
Exit Sub
MyErrorHandler:
'This code will not be executed if an error occurs in Combo1_Change...'
MsgBox "My error-handler called."
End Sub
If you compile the project and run the resulting EXE, you will get a run-time error whenever you click Command1 and the program will terminate. This is because the error handling code that was added (MyErrorHandler in the example) is not getting called. However, if you add error-handling code to the Combo1_Change event handler, you can catch the error and try to deal with it (at the very least, you can keep the program from crashing).
Therefore, I would make sure that every event procedure has error-handling code in it, and add it if it's missing. That should make it easier to pinpoint where the error is actually occurring. For example, if you have code in the cmbAIDFile_Change event procedure, make sure it has error-handling. I would add line numbers to your code as well (if you don't have them already): that way you can use Erl in your error-handling code to get the actual line number where the error occurred. See the following code for an example of how to log line numbers in your error messages.
Using Erl to report line numbers in error messages
Private Sub cmbAIDFile_Change()
1000 On Error Goto ErrorHandler
1010 DoSomething
1020 DoSomethingElse
ErrorHandler:
1030 Dim sErrMsg As String
sErrMsg = "A fatal error occurred." & vbCrLf & vbCrLf & _
"Method: cmbAIDFile_Change" & vbCrLf & _
"Line: " & Erl & vbCrLf & _
"Err.Number: " & Err.Number & vbCrLf & _
"Err.Description: " & Err.Description
1040 MsgBox sErrMsg, vbCritical+vbOKOnly, "Fatal error"
End Sub
Once you have more fine-grained error-handling in place, you can begin to investigate why you are seeing a problem on only one machine, because you should have much more reliable information about the error that is occurring, and be in a much better position to figure what the root cause is.