Access crashes when calling DLL function.

[BruceS]

(Running Access 2003 SP3 on WinXP Pro.)

OK, this one is driving me nuts.

I have a module created by a 3rd party vendor (ZipInfo) which calls
functions from a DLL they provide. It has worked flawlessly for over 6 years
in 4 other .mdbs.

I copied that module into a new front end mdb and added code to call one of
the functions in a form module. Now, whenever any of the DLL functions are
called from my code, Access crashes completely. No normal error that I can
trap. Just a bunch of reports back to MS.

I have stepped through every line of code looking for a problem. Nada. I
have verified the values being passed to the functions. They are OK. This
..mdb is not any larger megabytes-wize than the working ones. It's a
front-end mdb, but at this point there has not been any connections
established to other databases.

The strange part is that, if I put a break just before the DLL function call
and type the next command into the Immediate Window, it works fine. In fact,
all of the DLL functions and subs work perfectly in that manner. They only
fail when called by running code.

I have done everything Allen Browne suggests for many problems: Name
auto-correct is turned off. Only references that are absolutely needed are
loaded. I have copied everything into a new .mdb. I have decompiled and
recompiled.

I've spoken with the vendor, and they are at a loss. It's obviously not
their code because it works manually. Plus, the other applications that use
that DLL are still working great.

Here is the pertinent code:

(From the form.)
'Coding fields have been loaded. See if coding is available.
If OpenAddrDLL() = 0 Then GoTo ReloadAddress

myResult = CheckAddress(myBusiness, myURB, myAddr, myCSZ)

(From the DLL module Declarations.)

Private Declare Function UNZ_CHECKADDRESS Lib "UNZDLL32.DLL" (ByVal hUnz As
Long, ByVal Line1$, ByVal Line2$, ByVal Line3$, ByVal Line4$) As Long
....
' ** NOTE Variable Names Are being duplicated from documentation.
Public hUnz As Long 'This is the handle for the DLL.
....

(My function from the DLL module. Been used a long time.)

Public Function CheckAddress(Line1 As String, Line2 As String, Line3 As
String, Line4 As String) As String

CheckAddress = ""
' Call the DLL to check the address and get the result code

(Crashes if next line is run.)
Result = UNZ_CHECKADDRESS(hUnz, Line1, Line2, Line3, Line4)
CheckAddress = Str(Result) & "|"
....

Does anyone have any suggestions on how to track down and correct the
problem?

Thanks,
Bruce

 

[June7 via AccessMonster.com]

First, try to replicate the problem in another mdb. Go through the same steps
to create a new project. Also, instead of starting from scratch, copy one of
the working projects and then modify it.

 

[BruceS]

Thanks, June 7, but it didn't fix.

I took an existing, working .mdb that uses the DLL routines, copied and
renamed. Next, deleted all of the other modules, tables & queries except the
problem one, then copied them into the "new" database from my problem
project. No joy. Still crashes at same exact point.

I then built a simple input form (in the same mdb) that calls the crashing
function. It works, so there is something going on in the code of the
existing form. It is complex, but nothing outrageous. It does a lot of
input checking via calls to local tables, but I do those in the working
programs, as well.

Code-wise, the only thing I am doing differently in the bad program from
prior good ones is using the Split() function to create an array, then using
ReDim on that array. I bring this up because I've seen this kind of crash
when already-allocated memory was overwritten. Is this a valid concern?
Maybe I'm not doing something correctly. Here is a snippet of how I am doing
the ReDim:

Dim LinePart As Variant
....
LinePart = Split(a, " ", 10)
ReDim Preserve LinePart(10) As String

Unless this is a problem, I guess I'm going to have to re-build the form
from scratch to see if that works.

Thanks,
Bruce

 

[Graham Mandeno]

Hi Bruce

What are the four variables: myBusiness, myURB, myAddr and myCSZ? Are they
declared as string variables, or are they textboxes? Is it possible that
one of them is Null?

I'm just grasping at straws here, but a couple of things you could try are:

1. Change the declaration of CheckAddress to make all the LineX arguments
ByVal.

2. Change the declaration of UNZ_CHECKADDRESS to make all the LineX
arguments "As String" instead of using the implicit $ suffix.

With regard to your use of the Split function, is it possible to temporarily
comment out that code to see if it makes a difference? Also, you could try
declaring LinePart thus:
Dim LinePart() As String

I'm at a loss to explain why any of these suggestions should make a
difference, but anything might be worth a try!

 

[BruceS]

Thanks for replying, Graham. Always good to receive your input.

I have started bypassing code in the form to find the problem. Already
bypassed everything (and it's a lot) that preps the input data and just
forced known-valid test values for the function calls. That includes
bypassing all array creation and ReDim. It still fails on that form but
works on a second, very simple form.

The problem form is designed is show only controls that are flagged as being
active in a database record. The controls are then moved to new vertical
positions and the Detail height adjusted accordingly. I've already bypassed
the move/resize logic to no avail. Next step is to eliminate the record read.

To answer your specific questions, the "my.." are local String variables.
The first two function parameters are empty strings ("") 99.99% of the time,
but don't cause a failure that way with manual input, and haven't in the
past. I hesitate to change the functions because they have worked in the
past, but will give it a shot just to see.

Something in that particular form is interfering with the call. Guessing
memory usage somewhere, but have no way of knowing exactly where.

Hope all is well in kiwi land!

Thanks again,
Bruce

Hi Bruce

What are the four variables: myBusiness, myURB, myAddr and myCSZ? Are they
declared as string variables, or are they textboxes? Is it possible that
one of them is Null?

I'm just grasping at straws here, but a couple of things you could try are:

1. Change the declaration of CheckAddress to make all the LineX arguments
ByVal.

2. Change the declaration of UNZ_CHECKADDRESS to make all the LineX
arguments "As String" instead of using the implicit $ suffix.

With regard to your use of the Split function, is it possible to temporarily
comment out that code to see if it makes a difference? Also, you could try
declaring LinePart thus:
Dim LinePart() As String

I'm at a loss to explain why any of these suggestions should make a
difference, but anything might be worth a try!

--
Good Luck

Graham Mandeno [Access MVP]
Auckland, New Zealand

Thanks, June 7, but it didn't fix.

I took an existing, working .mdb that uses the DLL routines, copied and
renamed. Next, deleted all of the other modules, tables & queries except
the
problem one, then copied them into the "new" database from my problem
project. No joy. Still crashes at same exact point.

I then built a simple input form (in the same mdb) that calls the crashing
function. It works, so there is something going on in the code of the
existing form. It is complex, but nothing outrageous. It does a lot of
input checking via calls to local tables, but I do those in the working
programs, as well.

Code-wise, the only thing I am doing differently in the bad program from
prior good ones is using the Split() function to create an array, then
using
ReDim on that array. I bring this up because I've seen this kind of crash
when already-allocated memory was overwritten. Is this a valid concern?
Maybe I'm not doing something correctly. Here is a snippet of how I am
doing
the ReDim:

Dim LinePart As Variant
...
LinePart = Split(a, " ", 10)
ReDim Preserve LinePart(10) As String

Unless this is a problem, I guess I'm going to have to re-build the form
from scratch to see if that works.

Thanks,
Bruce

 

[BruceS]

Graham,

As usual, you were right! All of my tracking down resulted in an
uninitialized variable passed to the function. I initialized "myExtra" to
blank instead of "myURB", then made the call with myURB. When I put the
mouse cursor over the value, it still showed "", so I didn't catch it.

Ah, the lessons we learn the hard way.

Thanks,
Bruce

Hi Bruce

What are the four variables: myBusiness, myURB, myAddr and myCSZ? Are they
declared as string variables, or are they textboxes? Is it possible that
one of them is Null?

I'm just grasping at straws here, but a couple of things you could try are:

1. Change the declaration of CheckAddress to make all the LineX arguments
ByVal.

2. Change the declaration of UNZ_CHECKADDRESS to make all the LineX
arguments "As String" instead of using the implicit $ suffix.

With regard to your use of the Split function, is it possible to temporarily
comment out that code to see if it makes a difference? Also, you could try
declaring LinePart thus:
Dim LinePart() As String

I'm at a loss to explain why any of these suggestions should make a
difference, but anything might be worth a try!

--
Good Luck

Graham Mandeno [Access MVP]
Auckland, New Zealand

Thanks, June 7, but it didn't fix.

I took an existing, working .mdb that uses the DLL routines, copied and
renamed. Next, deleted all of the other modules, tables & queries except
the
problem one, then copied them into the "new" database from my problem
project. No joy. Still crashes at same exact point.

I then built a simple input form (in the same mdb) that calls the crashing
function. It works, so there is something going on in the code of the
existing form. It is complex, but nothing outrageous. It does a lot of
input checking via calls to local tables, but I do those in the working
programs, as well.

Code-wise, the only thing I am doing differently in the bad program from
prior good ones is using the Split() function to create an array, then
using
ReDim on that array. I bring this up because I've seen this kind of crash
when already-allocated memory was overwritten. Is this a valid concern?
Maybe I'm not doing something correctly. Here is a snippet of how I am
doing
the ReDim:

Dim LinePart As Variant
...
LinePart = Split(a, " ", 10)
ReDim Preserve LinePart(10) As String

Unless this is a problem, I guess I'm going to have to re-build the form
from scratch to see if that works.

Thanks,
Bruce

 

[Graham Mandeno]

Hi Bruce

I'm glad you got it sorted!

Interesting, there was exactly 24 hours between your last two posts. I was
asleep for both of them <g>

--
Good Luck

Graham Mandeno [Access MVP]
Auckland, New Zealand

Graham,

As usual, you were right! All of my tracking down resulted in an
uninitialized variable passed to the function. I initialized "myExtra" to
blank instead of "myURB", then made the call with myURB. When I put the
mouse cursor over the value, it still showed "", so I didn't catch it.

Ah, the lessons we learn the hard way.

Thanks,
Bruce

Hi Bruce

What are the four variables: myBusiness, myURB, myAddr and myCSZ? Are
they
declared as string variables, or are they textboxes? Is it possible that
one of them is Null?

I'm just grasping at straws here, but a couple of things you could try
are:

1. Change the declaration of CheckAddress to make all the LineX arguments
ByVal.

2. Change the declaration of UNZ_CHECKADDRESS to make all the LineX
arguments "As String" instead of using the implicit $ suffix.

With regard to your use of the Split function, is it possible to
temporarily
comment out that code to see if it makes a difference? Also, you could
try
declaring LinePart thus:
Dim LinePart() As String

I'm at a loss to explain why any of these suggestions should make a
difference, but anything might be worth a try!

--
Good Luck

Graham Mandeno [Access MVP]
Auckland, New Zealand

Thanks, June 7, but it didn't fix.

I took an existing, working .mdb that uses the DLL routines, copied and
renamed. Next, deleted all of the other modules, tables & queries
except
the
problem one, then copied them into the "new" database from my problem
project. No joy. Still crashes at same exact point.

I then built a simple input form (in the same mdb) that calls the
crashing
function. It works, so there is something going on in the code of the
existing form. It is complex, but nothing outrageous. It does a lot
of
input checking via calls to local tables, but I do those in the working
programs, as well.

Code-wise, the only thing I am doing differently in the bad program
from
prior good ones is using the Split() function to create an array, then
using
ReDim on that array. I bring this up because I've seen this kind of
crash
when already-allocated memory was overwritten. Is this a valid
concern?
Maybe I'm not doing something correctly. Here is a snippet of how I am
doing
the ReDim:

Dim LinePart As Variant
...
LinePart = Split(a, " ", 10)
ReDim Preserve LinePart(10) As String

Unless this is a problem, I guess I'm going to have to re-build the
form
from scratch to see if that works.

Thanks,
Bruce


:

First, try to replicate the problem in another mdb. Go through the
same
steps
to create a new project. Also, instead of starting from scratch, copy
one
of
the working projects and then modify it.

BruceS wrote:
(Running Access 2003 SP3 on WinXP Pro.)

OK, this one is driving me nuts.

I have a module created by a 3rd party vendor (ZipInfo) which calls
functions from a DLL they provide. It has worked flawlessly for over
6
years
in 4 other .mdbs.

I copied that module into a new front end mdb and added code to call
one
of
the functions in a form module. Now, whenever any of the DLL
functions
are
called from my code, Access crashes completely. No normal error that
I
can
trap. Just a bunch of reports back to MS.

I have stepped through every line of code looking for a problem.
Nada.
I
have verified the values being passed to the functions. They are OK.
This
.mdb is not any larger megabytes-wize than the working ones. It's a
front-end mdb, but at this point there has not been any connections
established to other databases.

The strange part is that, if I put a break just before the DLL
function
call
and type the next command into the Immediate Window, it works fine.
In
fact,
all of the DLL functions and subs work perfectly in that manner.
They
only
fail when called by running code.

I have done everything Allen Browne suggests for many problems: Name
auto-correct is turned off. Only references that are absolutely
needed
are
loaded. I have copied everything into a new .mdb. I have decompiled
and
recompiled.

I've spoken with the vendor, and they are at a loss. It's obviously
not
their code because it works manually. Plus, the other applications
that
use
that DLL are still working great.

Here is the pertinent code:

(From the form.)
'Coding fields have been loaded. See if coding is available.
If OpenAddrDLL() = 0 Then GoTo ReloadAddress

myResult = CheckAddress(myBusiness, myURB, myAddr, myCSZ)

(From the DLL module Declarations.)

Private Declare Function UNZ_CHECKADDRESS Lib "UNZDLL32.DLL" (ByVal
hUnz
As
Long, ByVal Line1$, ByVal Line2$, ByVal Line3$, ByVal Line4$) As Long
...
' ** NOTE Variable Names Are being duplicated from documentation.
Public hUnz As Long 'This is the handle for the DLL.
...

(My function from the DLL module. Been used a long time.)

Public Function CheckAddress(Line1 As String, Line2 As String, Line3
As
String, Line4 As String) As String

CheckAddress = ""
' Call the DLL to check the address and get the result code

(Crashes if next line is run.)
Result = UNZ_CHECKADDRESS(hUnz, Line1, Line2, Line3, Line4)
CheckAddress = Str(Result) & "|"
...

Does anyone have any suggestions on how to track down and correct the
problem?

Thanks,
Bruce