WinBatch Tech Support Home

Database Search

If you can't find the information using the categories below, post a question over in our WinBatch Tech Support Forum.

TechHome

Functions

Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.

WinExeName Returning a Null (blank) String on Some Systems

Keywords: 	 WinExeName	  Win2000 SP1 performance monitoring utilities blank string

Question:

I had some code working that used WinExeName() to get the exe's of open windows. The code recently stopped working -- that is, WinExeName is always returning a null string. My best recollection is that I haven't touched my code at all, and that the one major change I did to my system around the time the code stopped working was when I installed Service Pack 1 for Windows 2000. I am running Winbatch 2000C, DLL ver 3.0cbv. (I reinstalled it but no change.) Is this happening to anyone else? Can anyone reproduce it?

Answer:

Hmmm. It does require access to the registry to work.

We tested it on Win2000 SP1. No problems here. WinExename works fine.

Watch out for any performance monitoring utilities....some of them seem to have bugs that clobber WinExeName, AppExit and AppWaitCLose and sometimes SendKey.


Question 2:

We are having a problem with WinExeName returning a null string on Windows NT 4 machines...

Here is the bottom line:
Platform: NT4 sp5 (no hotfixes)
User: Administrator
Problem: WinEXEName() returns a blank string. This is different then a failure, because it indicates WinEXEName() is able to locate the window title, but is unable to return the EXE/module name; when an incorrect window title is given, an WBT error occurs.

; While the "InstallShield Wizard" windows is _not_ being generated by the IKERNEL process, wait.
; Parse the output of WinEXEName() because Win95 returns full path of IKERNEL.EXE while NT returns just the module name.
While StrLower(ItemExtract(1, ItemExtract(-1, WinExeName("InstallShield Wizard"), "\"), ".")) != "ikernel"
 TimeDelay(.5)
EndWhile
If I run this code on NT4, it loops forever because WinExeName is consistently returning a blank string!

For example, if you open NOTEPAD.EXE on the desktop of any of the offending NT4 workstations and run the following code:

Message("", WinExeName("Untitled"))
You will see a BLANK MESSAGE!

Which means WinEXEName() is finding the window title, but is unable to display the module name, agreed?

Because, If WinEXEName() was unable to locate the window title, we would see the following WBT error:

1172:Winexename window not found.

Herein lies our problem. Help!!!!!

Answer:

Thank you for such a concise explanation of the problem. To be honest, this is not a common problem. We have only heard of this once before, however this other user was running Windows 2000 SP1. (see previous question)

I tested the following code on my NT 4.0 SP6 machine and the the script ran flawlessly.

Run("Notepad.exe","")
WinWaitExist("Untitled",10)
Message(winversion(3), WinExeName("Untitled"))
I honestly believe it has to do with something particular to your NT 40.SP5 machine (probably performance monitoring).

I spoke to the developers about why the WinExeName function is returning a blank string on error, instead of erroring out with an error message. They said that, that was a 'design choice'. I then pointed out that the documentation doesn't state that a blank string/null is returned upon error. We are going update the documentation to make sure that it states that, upon error this function retruns a blank string. We will also add code that will write last error information to the wwwbatch.ini file.

Anyhow, The problem is mostly likely a cause of the inabilty of Winbatch to access 'performance monitoring' on the these *particular* machines.

If its only happening on one machine you might look into whether or not performance monitoring utilities could potentially get involved.... some of them seem to have bugs that clobber WinExeName, AppExist and AppWaitClose and sometimes SendKey.

Can you run the performance monitor 'perfmon.exe' on this machine? Can you see a list of processes listed, when you do a Ctrl-Alt-Delete? Make sure Performance counters are NOT disabled on this machine.

NOTE: This error could be a result of a known bug in Windows NT 4.0. When an application is repeatedly opening, closing, and reopening the key, it causes an internal reference counter to overflow, and RegOpenKeyEx to fail. Behind the scenes the WinExeName function accesses the 'Perflib' key in the registry to get process information. We open the key grab the info then close the key. Microsoft has confirmed this to be a problem in Windows NT 4.0. On Windows NT 4.0 starting with Service Pack 4 (SP4), the key can be opened and closed only 65,535 times. Note: This bug was corrected in Windows 2000.

To check if this bug is what might be the problem. Try rebooting the machine, and running the script again. if the problem is resolved, then you might consider getting the fix from Microsoft....A supported fix for NT 4.0 is now available from Microsoft, but it is only intended to correct the problem described and should be applied only to systems experiencing this specific problem. To resolve this problem, contact Microsoft Product Support Services to obtain the fix. For a complete list of Microsoft Product Support Services phone numbers and information on support costs, please go to the following address on the World Wide Web: http://support.microsoft.com/directory/overview.asp This information was gathered from the following Microsoft tech article: http://support.microsoft.com/support/kb/articles/Q237/3/04.ASP

We might however be able to get a more descriptive error from other functions that also attempt to access performance monitoring. Try executing the following scripts on the problem machine you might get a more descriptive error message, that *might* help you resolve the problem....

TEST ONE
------------------
DebugTrace(@on,"Test_One.txt")
Run("Notepad.exe","")
If AppExist("notepad.exe") == @FALSE 
   DirChange(DirWindows(0))
   Run("notepad.exe", "")
Endif


TEST TWO
------------------
DebugTrace(@on,"Test_Two.txt")
;This example uses the process extender.
AddExtender("wwprc44I.dll")
ret=tVersion()
Message("Task Extender Version",ret)
id=tListProc()
list=Askitemlist("List of all current processes",id,@TAB,@UNSORTED,@SINGLE)
if WinVersion(4) == 4 ;check if NT
; parse off process ID and Name
 procid=itemextract(2,list,"|")
 procname=itemextract(1,list,"|") 
 ret=tGetProcInfo(procid)
 pfc=itemextract(1,ret,@TAB)
 pwss=itemextract(2,ret,@TAB)
 wss= itemextract(3,ret,@TAB)
 qpppu=itemextract(4,ret,@TAB)
 qppu=itemextract(5,ret,@TAB)
 qpnppu= itemextract(6,ret,@TAB)
 qnppu=itemextract(7,ret,@TAB)
 pfu=itemextract(8,ret,@TAB)
 ppfu=itemextract(9,ret,@TAB)
 string=strcat("PageFaultcount",@TAB,pfc,@CRLF,"PeakWorkingSetSize",@TAB,pwss,@CRLF, "WorkingSetSize",@TAB,wss,@CRLF,"QuotaPeakPagedPoolUsage", @TAB,qpppu,@CRLF,"QuotaPagedPoolUsage",@TAB,qppu,@CRLF)
 string=strcat(string,"QuotaPeakNonPagedPoolUsage",@TAB,qpnppu,@CRLF, "QuotaNonPagedPoolUsage",@TAB,qnppu,@CRLF,"PagefileUsage", @TAB,pfu,@CRLF,"PeakPagefileUsage",@TAB,ppfu)
 message("Memory info on process %procname%",string)
else
 message("Cannot retireve Memory info on process","Not Running Win NT")
endif
exit

Article ID:   W14598
Filename:   WinExeName Returning a Null String on Some Systems.txt
File Created: 2013:04:01:09:16:24
Last Updated: 2013:04:01:09:16:24