HP UFT 12, 12.01 & 12.02 Crash during debugging phase

During the implementation of automated testing (with HP UFT 12 or 12.01 and rarely also with 11.53), during debugging, after a few clicks on F10 or F11 (Step Over and Step Into) we find that UFT crashes systematically .
With the same mode of development (we use an our internal framework), we note also that using QTP 11 or UFT 11.52 we can work without these technical problems (the tool does not crash; or if it does, it happens very very rarely, almost non-existent case).
Could someone help us out?

Thanks,
Andrea

Parents
  • Do you use record and playback or expert view?

     

    We are having a similar issue. We do not use record and playback. So we have a pair of fairly large function libraries which HP believes is causing the problem. But as you said, it was not an issue prior to 12. As far as memory is concerned, we use 4 per box, but I did bump one box up to 8 gigs and experienced the same behavior.

     

    If we come to some resolution, I will be certain to post here.

     

    Thanks,

    Ray

  • We did the same experiment, with same result. For all that concern the increasing of RAM.
    We use an our "custom framework" with many libraries; we don't have this issue with prior version of UFT (the best for us is UFT 11.52).

    actually we have to try UFT 12.02. I'll keep you informed.

     

    Andrew

  • Behavior very similar, same steps / actions, if we execute our code. Tomorrow we will perform your code on our workstations.

  • Behavior very similar, same steps / actions, if we execute our code. Tomorrow we will perform your code on our workstations.

  • Yes Trudy, I have a support case open right now with HP, and I have given them this same information.

     

    More additional information, we found today that when recreating that we are maxxing our our Network Interface Card (NIC).  No explanation why this is happening with UFT, but did not happen with QTP.

  • Yes Trudy, I have a support case open right now with HP, and I have given them this same information.

     

    More additional information, we found today that when recreating that we are maxxing our our Network Interface Card (NIC).  No explanation why this is happening with UFT, but did not happen with QTP.

  • Yes Trudy, I have a support case open right now with HP, and I have given them this same information.

     

    More additional information, we found today that when recreating that we are maxxing our our Network Interface Card (NIC).  No explanation why this is happening with UFT, but did not happen with QTP.

  • Tested your code on our framework and it locked up just as you stated.  UFT 12.02, Win7

  • I also reproduced the issue just now with another machine with UFT 12.02, Win 7, and 8 GB of RAM.

  • Hm, I'm not able to reproduce it with your code on UFT 12.02, Win7 x64. Although it was slow when I stepped through it (5 seconds or so), but after that it can jump to the next line. I'll find another machine to check with it.

     

    Update: just tried it on another machine on Windows 2008R2, found that it was quite slow, up to around 1 minute, but stil able to jump to the next row.

     

    How long did you wait for UFT to run to the next row?

  • I am seeing freezing that can last anywhere between 1 and 5 minutes, and occasionally, indefinitely. 

     

    With the help of HP Support, I've done some things to improve my situation.  Others might find useful.  However, some debug freezing issues still remain.

     

     1.  Search the entire registry for "pdm" (not "pdm.dll" - you won't find it that way).  Ensure that every value for every key with value being a path to pdm.dll is "C:\Program Files (x86)\Internet Explorer\pdm.dll".  If it's different, change it to that path.

     

    2.  Register the pdm.dll from the Start->Run prompt (not the Command Line because some entries might not be modified).  Type regsvr32 "C:\Program Files (x86)\Internet Explorer\pdm.dll".

     

    3.  To an extra step to ensure optimal debugging, also register msdbg2.dll.  Go to Start->Run.  Type regsvr32 "C:\Program Files (x86)\Internet Explorer\msdbg2".

     

    4.  Restart computer

     

    With these steps, I was able to watch about 5 variables at once (probably could watch a few more) in my watch list while walking through the code in our test from which the code snippet presented above was derived.  Prior to doing these steps, UFT would freeze while watching 2 or more variables, and this was worse performance than we were getting with QTP.

     

    HOWEVER...., if local variables tab is open, it will still freeze after calling the GetFolder method of the FileSystemObject. Also, if using just the watch list, if the return value (in this case "objFolder") for that call to GetFolder is in the watch list, it will freeze.

     

    I also found the same issue with our installations of QTP 11. So it appears UFT and QTP both have this problem.  Not sure if these issues are more exaggerated for the system we are in or the machines we are using.

     

    In summary, it looks like the GetFolder method for a FileSystemObject is hard for QTP or UFT to handle when watching the return value for that call. However, some of the steps above can help optimize debugging overall.  If anyone has anymore solutions or ideas for this issue, please post!

     

     

    ** I was also given other advice, see below, but didn't seem to have any major effect for me.  Might help someone though:

     

    1. Debugging issues may also be caused by the incorrect registration of the "Machine Debug Manager" (mdm.exe) component in the system. To register this component, please follow these steps:
      1. Find all mdm.exe files on your computer.
      2. Register each mdm.exe component by executing the following command:
        exe /regserver
        Note: Run the Command Prompt window using the Run as Administrator command (see below).
    • Restart the computer.
    1. If the problem remains, try the steps below:
      1. Close Visual Studio (if present/installed) and UFT.
      2. Check whether the VS7Debug folder is on your disk. As a rule, the folder is located here: "C:\Program Files\Common Files\Microsoft Shared\VS7Debug". Note: Check same under "C:\Program files (x86)"
    • If the folder exists, rename it to "_VS7Debug", for example.
    1. Reinstall Microsoft Script Debugger.
      If you are using Windows 7, Windows Vista or Windows Server 2008, it is recommended to install the debugger with administrator privileges.
    2. After the installation is over, check whether UFT loads the modules that do not belong to Visual Studio. You can do this, for example, via the Process Explorer window.
    1. If the debugger still does not work, run mdm.exe with administrator privileges.

     

     

  • I am seeing freezing that can last anywhere between 1 and 5 minutes, and occasionally, indefinitely. 

     

    With the help of HP Support, I've done some things to improve my situation.  Others might find useful.  However, some debug freezing issues still remain.

     

     1.  Search the entire registry for "pdm" (not "pdm.dll" - you won't find it that way).  Ensure that every value for every key with value being a path to pdm.dll is "C:\Program Files (x86)\Internet Explorer\pdm.dll".  If it's different, change it to that path.

     

    2.  Register the pdm.dll from the Start->Run prompt (not the Command Line because some entries might not be modified).  Type regsvr32 "C:\Program Files (x86)\Internet Explorer\pdm.dll".

     

    3.  To an extra step to ensure optimal debugging, also register msdbg2.dll.  Go to Start->Run.  Type regsvr32 "C:\Program Files (x86)\Internet Explorer\msdbg2".

     

    4.  Restart computer

     

    With these steps, I was able to watch about 5 variables at once (probably could watch a few more) in my watch list while walking through the code in our test from which the code snippet presented above was derived.  Prior to doing these steps, UFT would freeze while watching 2 or more variables, and this was worse performance than we were getting with QTP.

     

    HOWEVER...., if local variables tab is open, it will still freeze after calling the GetFolder method of the FileSystemObject. Also, if using just the watch list, if the return value (in this case "objFolder") for that call to GetFolder is in the watch list, it will freeze.

     

    I also found the same issue with our installations of QTP 11. So it appears UFT and QTP both have this problem.  Not sure if these issues are more exaggerated for the system we are in or the machines we are using.

     

    In summary, it looks like the GetFolder method for a FileSystemObject is hard for QTP or UFT to handle when watching the return value for that call. However, some of the steps above can help optimize debugging overall.  If anyone has anymore solutions or ideas for this issue, please post!

     

     

    ** I was also given other advice, see below, but didn't seem to have any major effect for me.  Might help someone though:

     

    1. Debugging issues may also be caused by the incorrect registration of the "Machine Debug Manager" (mdm.exe) component in the system. To register this component, please follow these steps:
      1. Find all mdm.exe files on your computer.
      2. Register each mdm.exe component by executing the following command:
        exe /regserver
        Note: Run the Command Prompt window using the Run as Administrator command (see below).
    • Restart the computer.
    1. If the problem remains, try the steps below:
      1. Close Visual Studio (if present/installed) and UFT.
      2. Check whether the VS7Debug folder is on your disk. As a rule, the folder is located here: "C:\Program Files\Common Files\Microsoft Shared\VS7Debug". Note: Check same under "C:\Program files (x86)"
    • If the folder exists, rename it to "_VS7Debug", for example.
    1. Reinstall Microsoft Script Debugger.
      If you are using Windows 7, Windows Vista or Windows Server 2008, it is recommended to install the debugger with administrator privileges.
    2. After the installation is over, check whether UFT loads the modules that do not belong to Visual Studio. You can do this, for example, via the Process Explorer window.
    1. If the debugger still does not work, run mdm.exe with administrator privileges.

     

     

Reply
  • I am seeing freezing that can last anywhere between 1 and 5 minutes, and occasionally, indefinitely. 

     

    With the help of HP Support, I've done some things to improve my situation.  Others might find useful.  However, some debug freezing issues still remain.

     

     1.  Search the entire registry for "pdm" (not "pdm.dll" - you won't find it that way).  Ensure that every value for every key with value being a path to pdm.dll is "C:\Program Files (x86)\Internet Explorer\pdm.dll".  If it's different, change it to that path.

     

    2.  Register the pdm.dll from the Start->Run prompt (not the Command Line because some entries might not be modified).  Type regsvr32 "C:\Program Files (x86)\Internet Explorer\pdm.dll".

     

    3.  To an extra step to ensure optimal debugging, also register msdbg2.dll.  Go to Start->Run.  Type regsvr32 "C:\Program Files (x86)\Internet Explorer\msdbg2".

     

    4.  Restart computer

     

    With these steps, I was able to watch about 5 variables at once (probably could watch a few more) in my watch list while walking through the code in our test from which the code snippet presented above was derived.  Prior to doing these steps, UFT would freeze while watching 2 or more variables, and this was worse performance than we were getting with QTP.

     

    HOWEVER...., if local variables tab is open, it will still freeze after calling the GetFolder method of the FileSystemObject. Also, if using just the watch list, if the return value (in this case "objFolder") for that call to GetFolder is in the watch list, it will freeze.

     

    I also found the same issue with our installations of QTP 11. So it appears UFT and QTP both have this problem.  Not sure if these issues are more exaggerated for the system we are in or the machines we are using.

     

    In summary, it looks like the GetFolder method for a FileSystemObject is hard for QTP or UFT to handle when watching the return value for that call. However, some of the steps above can help optimize debugging overall.  If anyone has anymore solutions or ideas for this issue, please post!

     

     

    ** I was also given other advice, see below, but didn't seem to have any major effect for me.  Might help someone though:

     

    1. Debugging issues may also be caused by the incorrect registration of the "Machine Debug Manager" (mdm.exe) component in the system. To register this component, please follow these steps:
      1. Find all mdm.exe files on your computer.
      2. Register each mdm.exe component by executing the following command:
        exe /regserver
        Note: Run the Command Prompt window using the Run as Administrator command (see below).
    • Restart the computer.
    1. If the problem remains, try the steps below:
      1. Close Visual Studio (if present/installed) and UFT.
      2. Check whether the VS7Debug folder is on your disk. As a rule, the folder is located here: "C:\Program Files\Common Files\Microsoft Shared\VS7Debug". Note: Check same under "C:\Program files (x86)"
    • If the folder exists, rename it to "_VS7Debug", for example.
    1. Reinstall Microsoft Script Debugger.
      If you are using Windows 7, Windows Vista or Windows Server 2008, it is recommended to install the debugger with administrator privileges.
    2. After the installation is over, check whether UFT loads the modules that do not belong to Visual Studio. You can do this, for example, via the Process Explorer window.
    1. If the debugger still does not work, run mdm.exe with administrator privileges.

     

     

Children
No Data