0

Recently we moved classic asp application+ vb6 com components from W2K3 server to W2K8 server. The only change made in the vb6 component is upgrade from MSXML 2.0 to MSXML 6.0. These vb6 components are compiled into dlls and registered as COM components on the server. The issue we are facing right now is that asp pages are taking a lot of time to load. The functionality which used to take 8-10 sec is now taking around 40 seconds. We inserted the logs and found that all the functions in vb6 code which are related to MSXML 6.0 upgrade have caused the slowness in the application.

On further research, we found that vb6 modules which uses 64 bit version of MSXML6.0(present under C:\Windows\System32) to load XML documents takes over two times longer to load an xml doc which uses 32bit version of MSXML6.0. (present under C:\Windows\sysWOW64)

Microsoft has provided a hotfix for this. Please see below url. http://support.microsoft.com/kb/2799406 We already tried this hotfix but it did not fixed the performance issue.

Question: 1) On W2K8 machine, we are unable to use MSXML6.0 present under C:\Windows\sysWOW64. Whenever we try to reference to this location it by default references back to C:\Windows\system32. We also opened the vb project file in a notepad and changed the reference location and opened the Project again but no success. Can anyone suggest what can be the probable solution to fix this? Current Scenario: Reference=*\G{F5078F18-C551-11D3-89B9-0000F81FE221}#6.0#0#..\WINDOWS\System32\msxml6.dll#Microsoft XML, v6.0

Expected Scenario: Reference=*\G{F5078F18-C551-11D3-89B9-0000F81FE221}#6.0#0#..\WINDOWS\sysWOW64\msxml6.dll#Microsoft XML, v6.0

2) Once we compile this vb6 code to a dll by having a reference to this sysWOW64 folder, how to ensure/confirm reference from Syswow64 will be picked up once it will be on W2K8 server?

3) Also if you can suggest what can be other areas we should target/think of for resolving this performance issue?

user1427816
  • 43
  • 1
  • 5
  • The 32-bit MSXML library is almost certainly being used, you are being confused by how SysWOW redirection works. This is an in-process DLL, so there isn't even any practical way for 32-bit code to load and call the 64-bit copy. – Bob77 Nov 21 '14 at 17:02
  • As far as I can tell KB2799406 does not apply. – Bob77 Nov 21 '14 at 17:04
  • Hi Bob, If you are so sure that it will anyway redirect and use 32bit libraries can you tell what can be the reason behind this performance issue? – user1427816 Nov 22 '14 at 20:51
  • We have further drilled down the code and identified the functionality which is causing the slowness. It is pure XML processing where in a particular node has been searched using nodelist and then taking the value from the element and assigning it to object properties. Sorry I cant post the code here.. – user1427816 Nov 22 '14 at 20:54
  • Can you be sure your script is being run in the 32-bit engine, and not using expensive thunks to reach from 64-bit script to your 32-bit DLL? On 64-bit Windows there are two VBScript engines. You may have the wrong AppPool settings in IIS. – Bob77 Nov 23 '14 at 19:03

0 Answers0