SWDD Transaction crashes in SAP GUI 7.4 (App-V 5.0)

2015-06-24 10_53_42-SAP Easy Access

 

SAP officially supports (thanks to Microsoft)  SAP GUI (7.3 and 7.4) running as an App-V 5.0 package.

However after following the official recipe from Microsoft, which is available here, a certain transaction always crashed in SAP GUI 7.4.

After digging around a bit with my 2nd favourite swiss army knife tool “procmon.exe” (1st place goes to “APIMonitor”) I spotted a buffer overflow while reading out the InProcServer32 of the “sapnetz.ocx” COM DLL. Im actually not yet sure if this was the root cause of the crash, however this led me to the decision to shorten the path to this DLL.

How? The recipe guides us to use “C:\Program Files (x86)\SAP” as “PVAD / Primary Installation directory”.  This PVAD or “Root” folder has physically the shortest path length of basically everything inside the App-V Package (Everything else is mapped using the VFS Structure).

My decision was to use a deeper definition of the PVAD Folder: C:\Program Files (x86)\SAP\FrontEnd.

This made the real physical path to “sapnetz.ocx” a bit shorter (less characters)  which may not explode the buffer which is reserved for that string.

And Yes… it seemed to work. “swdd” transaction does not crash any more.

So what else should you consider for “your” SAP GUI Package?

  • COM and Named Objects interaction must be enabled, otherwise some IE related stuff will fail
  • Follow the instructions regarding the “common” folder, however create this one in “C:\Program Files (x86)\SAP\FrontEnd\” and adjust the PATH variable accordingly.
  • Regarding BEX:
    • BEX must be in a separate package, as COM and Named Objects interaction may not be enabled. You also can’t join them together using “connection groups” as they require similar Interaction settings.
    • The main SAP components must also be a part of this package. Remove the shortcuts and file extensions of SAPGUI to have separate packages.

Regards,

Fabio

 

 

 

  • Tim

    Glad you solved the problem but….
    Whenever you see a “buffer overflow” in procmon, it is a GOOD thing. It only appears when an API is called that allocates a buffer that is too small. The overflow is prevented, but the API gets that failure and reallocates a big enough buffer. I’ll bet that if you have that trace still around, you will immediately see the same call succeed within the next 3 trace elements.

    Tim