CopyMemory API Crash At Windows 2012 Server

cheer

Registered User.
Local time
Today, 09:05
Joined
Oct 30, 2009
Messages
222
Program show crash after migrated from Windows 2003 Server to Windows 2012 Server and crash happen at CopyMemory

Public Function GetClientName() As String
Dim strClientName As String
Dim strCharacter As String
Dim intLoop As Integer
Dim pBuffer As Long
Dim dwSize As Long
GetClientName = ""
If WTSQuerySessionInformation(0, -1, 10, pBuffer, dwSize) Then
Dim clientName As String
clientName = String(dwSize, 0)
CopyMemory ByVal StrPtr(clientName), ByVal pBuffer, dwSize
WTSFreeMemory pBuffer
strClientName = clientName

For intLoop = 1 To Len(strClientName)
strCharacter = Trim(Mid(strClientName, intLoop, 1))
If (Asc(strCharacter) >= 48 And Asc(strCharacter) <= 57) Or (Asc(strCharacter) >= 65 And Asc(strCharacter) <= 90) Or _
(Asc(strCharacter) >= 97 And Asc(strCharacter) <= 122) Then
Debug.Print Asc(strCharacter)
GetClientName = GetClientName & strCharacter
End If
Next intLoop
End If
End Function

Can anyone help to modify the code ?
 
When you migrated, did you stay with the same version of Access or did you install a newer version thereof?
 
When you migrated, did you stay with the same version of Access or did you install a newer version thereof?

In Windows 2003 Server, I am using the Ms Access 2000 - 32 bits

In Windows 2012 Server, I am using the Ms Access 2016 - 64 bits
 
there are different declaration for API CopyMemory, depending if you are using x86 or x64 system.

for 32bit system:
Declare PtrSafe Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (Destination As Any, Source As Any, ByVal Length As Long)

while on x64 system:
Declare PtrSafe Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (Destination As Any, Source As Any, ByVal Length As LongPtr)

if you want to use it in either system:
Code:
#if win64 then
	Declare PtrSafe Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (Destination As Any, Source As Any, ByVal 	Length As LongPtr)
#else
	Declare PtrSafe Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (Destination As Any, Source As Any, ByVal 	Length As Long)
#end if
the last argument of this sub is LongPtr for x64 while Long on x86.
on your code it uses this argument (Dim dwSize), therefore you should also enclosed in in the #if tag.

#if win64 then
dim dwSize As LongPtr
#else
dim dwSize As Long
#end if

when you compile your app, there will be warning msg that you will encounter, try fixing them. converting Long to LongPtr as necessary.

Goodluck.
 
there are different declaration for API CopyMemory, depending if you are using x86 or x64 system.

for 32bit system:
Declare PtrSafe Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (Destination As Any, Source As Any, ByVal Length As Long)

while on x64 system:
Declare PtrSafe Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (Destination As Any, Source As Any, ByVal Length As LongPtr)

if you want to use it in either system:
Code:
#if win64 then
    Declare PtrSafe Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (Destination As Any, Source As Any, ByVal     Length As LongPtr)
#else
    Declare PtrSafe Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (Destination As Any, Source As Any, ByVal     Length As Long)
#end if
the last argument of this sub is LongPtr for x64 while Long on x86.
on your code it uses this argument (Dim dwSize), therefore you should also enclosed in in the #if tag.

#if win64 then
dim dwSize As LongPtr
#else
dim dwSize As Long
#end if

when you compile your app, there will be warning msg that you will encounter, try fixing them. converting Long to LongPtr as necessary.

Goodluck.


I have amended my codes as written on the above, however, the program still crash.

Do I need to do anything on WTSQuerySessionInformation ?

Private Declare PtrSafe Function WTSQuerySessionInformation Lib "wtsapi32.dll" Alias "WTSQuerySessionInformationW" _
(ByVal hServer As Long, ByVal SessionId As Long, ByVal wtsInfoClass As Long, ByRef pBuffer As Long, ByRef dwSize As LongPtr) As Long
 
I have no reference on this function. Better goggle its corrwct x64 equivalent.
 
To use your program with both 32 bit & 64 bit Access, all your declarations need to be handled in the same way in every module

Code:
#If Win64 Then
'add 64 bit declaration
#Else
'32 bit declaration here
#End If

For 64 bit, use
Code:
 Declare PtrSafe ....
And replace all instances of Long with LongPtr

Compile in 32 bit then test in 64 bit
Open holding down the Shift key to bypass all start up conditions
Try compiling again. If its ok, open it normally.

NOTE: in 64 bit, all 32 bit sections of your declarations will be shown in red.
That's normal. Don't panic!
 
You should also know that some 32-bit non-Access library references don't have a 64-bit counterpart, so even those references can get tricky. Your crash is almost certainly that you ran afoul of an interface mismatch.

There are two ways to approach this, though. The idea of slogging through the calls and references is viable if slow. But do you really NEED the 64-bit version of Office (or just Access, if that is all you are using)? If you are working with SharePoint, I'm told that you might need it, but if not, you might make better headway by uninstalling Access 64-bit and installing Access 32-bit. Access itself does not (currently) take advantage of the longer address length so you can't make a bigger database with 64-bit Access. Same 2GB size limit still applies.

Just a thought, and there certainly CAN be reasons why you needed 64-bit.
 
Doc's raised a very important point.

Only use 64-bit Access if absolutely necessary - it currently has few/no advantages and lots of disadvantages.

However if you have clients that use it, you have little choice other than to work with it.

For example, two libraries that don't work in 64-bit Access are those associated with mousehook.dll & flexgrid.ocx. Also some calendar controls
 
I manage to fix some crash, however, the result is not something I am looking for. You can click the attachment below to understand further.

Can anyone share with me how to fix the problems ?
 

Attachments

  • Different.png
    Different.png
    39.9 KB · Views: 186

Users who are viewing this thread

Back
Top Bottom