why a classic asp + vb6 component application using MSXML6.0 is slower on W2K8 server compare to W2K3 server? RRS feed

  • Question

  • 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.


    We already tried this hotfix but it did not fixed the performance issue.


    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?

    Friday, November 21, 2014 5:54 AM

All replies

  • I have encountered the exact same problem with msxml6.dll that is described in the latter part of you statement. Had you come up with a possible solution?

    Thursday, March 5, 2015 3:31 PM