Mongrel users - Mar 2007 - mongrel_service fails to get "service.exe" from ppid?

Konnichiwa Mongrel users,


mongrel_service cannot run as a windows service under my environment,
with the windows message :
"error 1053 : The service did not respond to the start or control
request in a timely fashion."


>From a part of "ServiceFB.log" at c:/ruby/bin,
mongrel_service failed to get the process name of "service.exe".
>ServiceController.RunMode()
>CurrentPID: 540
>ParentPID: 716
>Parent Name: <unknown>
>ServiceController.RunMode() done

and a part of "gem list" is ;
>mongrel (1.0.1)
>mongrel_service (0.3.1)
>rails (1.2.3, 1.2.2)
>win32-service (0.5.2)


I guess that the reason is my environment a bit complex and weird,
* Windows XP Professional x64 Version2003 SP1
* over VMWare Server 1.0.1
*   over Windows Server 2003 R2 Standard x64

In fact,
I''ve confirmed that the mongrel_service and my webapp run well as a
windows service under Windows XP 32bit edition,
and both of
> mongrel_rails start
> mongrel_service console single -c [path/to/mywebapp] -p 3000 -e development
run correctry even on such win64 stacks.


Can anyone shed any light?

On 3/26/07, blindance at gmail.com <blindance at gmail.com>
wrote:
> Konnichiwa Mongrel users,
>
>
> mongrel_service cannot run as a windows service under my environment,
> with the windows message :
> "error 1053 : The service did not respond to the start or control
> request in a timely fashion."
>
>
>
> >From a part of "ServiceFB.log" at c:/ruby/bin,
> mongrel_service failed to get the process name of "service.exe".
>
> >ServiceController.RunMode()
> >CurrentPID: 540
> >ParentPID: 716
> >Parent Name: <unknown>
> >ServiceController.RunMode() done
>
Ok, it seems WinAPI behaves different on x64 environment compared to
normal 32bits.

Please note that ruby, mongrel and mongrel_service are 32bits
compilation, that will require some compatibility layer to run over
x64 Windows.

services run under windows (32bits) with "services.exe" as parent
process. Could you use ProcessExplorer [1] to check other services
working and who its process parent?

[1]
http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/ProcessExplorer.mspx
>
> and a part of "gem list" is ;
> >mongrel (1.0.1)
> >mongrel_service (0.3.1)
> >rails (1.2.3, 1.2.2)
> >win32-service (0.5.2)
>
>
>
> I guess that the reason is my environment a bit complex and weird,
> * Windows XP Professional x64 Version2003 SP1
> * over VMWare Server 1.0.1
> *   over Windows Server 2003 R2 Standard x64
>
> In fact,
> I''ve confirmed that the mongrel_service and my webapp run well as
a
> windows service under Windows XP 32bit edition,
> and both of
> > mongrel_rails start
> > mongrel_service console single -c [path/to/mywebapp] -p 3000 -e
development
> run correctry even on such win64 stacks.
>
>
> Can anyone shed any light?
forcing mongrel_service to start in console mode will work always,
since the "magic trick" used to get parent process isn''t used
at all.

on Win32, services run as child process (spawned) by "services.exe"
=>
"Services and Controller app"

I guess that''s the problem under x64.

I attached a 7z file with proc_info.exe, which will test if the WinAPI
used works. Please run it front the command line, the expected output
will be:

this process (PID, name): 3484, proc_info.exe
parent process (PID, name): 3924, cmd.exe

If that works, that means the Services and Controller application
(services.exe) is named differently under x64, or due 32bits
compatibility run as child process of _another_ process :-P

With that information I could patch mongrel_service current version :-)

Regards,

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proc_info.7z
Type: application/octet-stream
Size: 8458 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/mongrel-users/attachments/20070326/69e7c7e5/attachment-0001.obj

Thank you very much for your cooperation and sooner response,

>services run under windows (32bits) with "services.exe" as parent
>process. Could you use ProcessExplorer [1] to check other services
>working and who its process parent?

Yes, as same as Win32,
"services.exe" is the parent process of "svchost.exe",
"snmp.exe" ,
"mysqld-nt.exe", "VMwareService.exe", etc.
and only "services.exe" and "svchost.exe" is 64-bit image.

I''m sorry that "service.exe" in the subject is a TYPO.


>I attached a 7z file with proc_info.exe, which will test if the WinAPI
>used works. Please run it front the command line, the expected output
>will be:
The result is :
 this process (PID, name): 2192, proc_info.exe
 parent process (PID, name): 3024, <unknown>


"<unknown>" is the error or the warning word returned by
"_process_name" function of ServiceFB.
and "_process_name" function uses Win32API "HANDLE" typedef
via FreeBasic libs,
and the size of HANDLE of Win32API differs from the other one of Win64API.

so, if "proc_info.exe" is getting its process name without its PID,
I guess that the root of this compatibility problem will exist around here.
#if so, Perhaps I should not be bothering you with this...


> If that works, that means the Services and Controller application
> (services.exe) is named differently under x64, or due 32bits
> compatibility run as child process of _another_ process :-P
> With that information I could patch mongrel_service current version :-)
mmm, How about these results?


Sincerely,

On 3/27/07, blindance at gmail.com <blindance at gmail.com>
wrote:
> Thank you very much for your cooperation and sooner response,
>
>
> >services run under windows (32bits) with "services.exe" as
parent
> >process. Could you use ProcessExplorer [1] to check other services
> >working and who its process parent?
>
>
> Yes, as same as Win32,
> "services.exe" is the parent process of "svchost.exe",
"snmp.exe" ,
> "mysqld-nt.exe", "VMwareService.exe", etc.
> and only "services.exe" and "svchost.exe" is 64-bit
image.
>
> I''m sorry that "service.exe" in the subject is a TYPO.
>
The typo wasn''t a problem ;-)
>
>
> >I attached a 7z file with proc_info.exe, which will test if the WinAPI
> >used works. Please run it front the command line, the expected output
> >will be:
>
> The result is :
>  this process (PID, name): 2192, proc_info.exe
>  parent process (PID, name): 3024, <unknown>
>
>
> "<unknown>" is the error or the warning word returned by
> "_process_name" function of ServiceFB.
> and "_process_name" function uses Win32API "HANDLE"
typedef via FreeBasic libs,
> and the size of HANDLE of Win32API differs from the other one of Win64API.
>
Actually, by default _process_name uses "<unknown>" as default
string,
since some cases getting process name seems to fail... like in *this*
case.

_process_name is used for both calls, one getting
_process_name(GetCurrentProcessId()) and the second getting
_process_name from _parent_process(GetCurrentProcessId())
> so, if "proc_info.exe" is getting its process name without its
PID,
> I guess that the root of this compatibility problem will exist around here.
> #if so, Perhaps I should not be bothering you with this...
>
If Parent PID number (3024) matched cmd.exe in this case, it seems the
problem isn''t related to _process_name.
>
>
> > If that works, that means the Services and Controller application
> > (services.exe) is named differently under x64, or due 32bits
> > compatibility run as child process of _another_ process :-P
> > With that information I could patch mongrel_service current version
:-)
>
> mmm, How about these results?
>
>
These shows me almost every function is working, but maybe enumerating
running process (using PSAPI) is failing.

I''ll try to GDB tonight and compare 32bits with x64 API callings.

Thanks for your reply :-)

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

Ok, a follow up on this issue:


On 3/27/07, Luis Lavena <luislavena at gmail.com>
wrote:
> [...]
> >
> > Yes, as same as Win32,
> > "services.exe" is the parent process of
"svchost.exe", "snmp.exe" ,
> > "mysqld-nt.exe", "VMwareService.exe", etc.
> > and only "services.exe" and "svchost.exe" is
64-bit image.
> >
> > [...]
> >
> > The result is :
> >  this process (PID, name): 2192, proc_info.exe
> >  parent process (PID, name): 3024, <unknown>
> >
> >
> > "<unknown>" is the error or the warning word returned
by
> > "_process_name" function of ServiceFB.
> > and "_process_name" function uses Win32API
"HANDLE" typedef via FreeBasic libs,
> > and the size of HANDLE of Win32API differs from the other one of
Win64API.
> >
>
Ok, guess I have found the problem, quoting msdn article [1]:


"If the specified process is a 64-bit process and the caller is a
32-bit process, this call will fail. Note that you can use the
QueryFullProcessImageName function to retrieve the full name of an
executable image for both 32- and 64-bit processes from a 32-bit
process."


[1] http://msdn2.microsoft.com/en-us/library/ms682489.aspx


BUT, there is always a "but"...

QueryFullProcessImageName is only available in Server 2003 or Vista...
which will be incompatible with XP... since xp psapi.dll don''t
implement it.

I''ll try to figure some workaround on this matter.

This is actually a "cross-platform" issue, between Win32 and WOW64 :-P

Could you test the attached file?

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proc_info.7z
Type: application/octet-stream
Size: 16182 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/mongrel-users/attachments/20070331/1a313eb5/attachment.obj

Sure, we''ll give it a shot on Monday. Thanks for the follow-up.

On 3/30/07, Luis Lavena <luislavena at gmail.com>
wrote:
> Ok, a follow up on this issue:
>
>
> On 3/27/07, Luis Lavena <luislavena at gmail.com> wrote:
> > [...]
> > >
> > > Yes, as same as Win32,
> > > "services.exe" is the parent process of
"svchost.exe", "snmp.exe" ,
> > > "mysqld-nt.exe", "VMwareService.exe", etc.
> > > and only "services.exe" and "svchost.exe" is
64-bit image.
> > >
> > > [...]
> > >
> > > The result is :
> > >  this process (PID, name): 2192, proc_info.exe
> > >  parent process (PID, name): 3024, <unknown>
> > >
> > >
> > > "<unknown>" is the error or the warning word
returned by
> > > "_process_name" function of ServiceFB.
> > > and "_process_name" function uses Win32API
"HANDLE" typedef via FreeBasic libs,
> > > and the size of HANDLE of Win32API differs from the other one of
Win64API.
> > >
> >
>
> Ok, guess I have found the problem, quoting msdn article [1]:
>
>
> "If the specified process is a 64-bit process and the caller is a
> 32-bit process, this call will fail. Note that you can use the
> QueryFullProcessImageName function to retrieve the full name of an
> executable image for both 32- and 64-bit processes from a 32-bit
> process."
>
>
> [1] http://msdn2.microsoft.com/en-us/library/ms682489.aspx
>
>
> BUT, there is always a "but"...
>
> QueryFullProcessImageName is only available in Server 2003 or Vista...
> which will be incompatible with XP... since xp psapi.dll don''t
> implement it.
>
> I''ll try to figure some workaround on this matter.
>
> This is actually a "cross-platform" issue, between Win32 and
WOW64 :-P
>
> Could you test the attached file?
>
> --
> Luis Lavena
> Multimedia systems
> -
> Leaders are made, they are not born. They are made by hard effort,
> which is the price which all of us must pay to achieve any goal that
> is worthwhile.
> Vince Lombardi
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
>

-- 
-Matt McKnight-
www.lmnsolutions.com

Thank you,

> This is actually a "cross-platform" issue, between Win32 and
WOW64 :-P
> Could you test the attached file?
XPSP2 x64
 this process (PID, name): 2192, proc_info.exe
 parent process (PID, name): 3592, <unknown>
 Couldn''t create Snapshot
 parent process by thunk (PID, name): 3592, <unknown>


2003SP1 x64
 this process (PID, name): 420, proc_info.exe
 parent process (PID, name): 648, <unknown>
 Couldn''t create Snapshot
 parent process by thunk (PID, name): 648, <unknown>


mmm... I guess nothing is changed from the previous proc_info...

On 4/2/07, blindance at gmail.com <blindance at gmail.com>
wrote:
> Thank you,
>
>
> > This is actually a "cross-platform" issue, between Win32 and
WOW64 :-P
> > Could you test the attached file?
>
> XPSP2 x64
>  this process (PID, name): 2192, proc_info.exe
>  parent process (PID, name): 3592, <unknown>
>  Couldn''t create Snapshot
>  parent process by thunk (PID, name): 3592, <unknown>
>
>
> 2003SP1 x64
>  this process (PID, name): 420, proc_info.exe
>  parent process (PID, name): 648, <unknown>
>  Couldn''t create Snapshot
>  parent process by thunk (PID, name): 648, <unknown>
>
>
> mmm... I guess nothing is changed from the previous proc_info...
Guess it didn''t...

Third round, hope this time we get it right, expected output:

*** CURRENT PROCESS ***
EnumProcessModules (PID, name): 3128      proc_info.exe
Module32First (PID, name): 3128           proc_info.exe
GetProcessImageFileName (PID, name): 3128 \Device\HarddiskVolume5\Programming\So
urces\_sandbox\proc_info.exe

*** PARENT PROCESS ***
EnumProcessModules (PID, name): 4084      cmd.exe
Module32First (PID, name): 4084           cmd.exe
GetProcessImageFileName (PID, name): 4084 \Device\HarddiskVolume2\WINDOWS\system
32\cmd.exe

WinAPI documentation is too confusing about 32-bits process listing
64-bits modules or process... also there is a lot of functions that do
the same from different approaches that aren''t compatibles with
previous version of windows.

(i.e. QueryFullProcessImageName is only available in Vista and Windows
Server "Longhorn")...

Maybe I could code some dynamic loading (like psapi in proc_info) to
workaround this case scenario.

Please let me know the results.

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proc_info_3.7z
Type: application/octet-stream
Size: 12719 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/mongrel-users/attachments/20070402/ace1f5f3/attachment-0001.obj

<snip>
 
> Maybe I could code some dynamic loading (like psapi in 
> proc_info) to workaround this case scenario.
> 
> Please let me know the results.
Are you just trying to get process information? The sys-proctable
package works on MS Windows. I dropped the psapi approach a long time
ago in favor of OLE + WMI. So long as the WMI service is running, it
should work on any Windows platform.

Regards,

Dan


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.

On 4/2/07, Berger, Daniel <Daniel.Berger at qwest.com>
wrote:
> <snip>
>
> > Maybe I could code some dynamic loading (like psapi in
> > proc_info) to workaround this case scenario.
> >
> > Please let me know the results.
>
> Are you just trying to get process information? The sys-proctable
> package works on MS Windows. I dropped the psapi approach a long time
> ago in favor of OLE + WMI. So long as the WMI service is running, it
> should work on any Windows platform.
>
Thanks Dan for the information, but OLE + WMI is overkill for the
task. Since I support XP, 2003 and Vista on 32bits platforms, using
psapi way is what I wanted.

The dynamic loading of functions under x64 platforms is though, but
could work around it (also, waiting for my OEM Vista to arrive... damn
postal parcels!)

The funny thing is "So long as the WMI service is running" ;-)

Also, I dropped win32-service support on previous releases for a
native, compiled implementation that don''t hook or crash the RubyVM
used by Mongrel. Which worked better, until users start jumping to x64
platforms ;-)

Guess that my platform upgrade will be sooner than expected.

Regards,

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

> -----Original Message-----
> From: mongrel-users-bounces at rubyforge.org 
> [mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Luis Lavena
> Sent: Monday, April 02, 2007 1:26 PM
> To: mongrel-users at rubyforge.org
> Subject: Re: [Mongrel] mongrel_service fails to get 
> "service.exe" from ppid?
> 
> 
> On 4/2/07, Berger, Daniel <Daniel.Berger at qwest.com> wrote:
> > <snip>
> >
> > > Maybe I could code some dynamic loading (like psapi in
> > > proc_info) to workaround this case scenario.
> > >
> > > Please let me know the results.
> >
> > Are you just trying to get process information? The sys-proctable 
> > package works on MS Windows. I dropped the psapi approach a 
> long time 
> > ago in favor of OLE + WMI. So long as the WMI service is 
> running, it 
> > should work on any Windows platform.
> >
> 
> Thanks Dan for the information, but OLE + WMI is overkill for 
> the task. Since I support XP, 2003 and Vista on 32bits 
> platforms, using psapi way is what I wanted.
Overkill? It''s abstracted away for you:

require ''sys/proctable''
include Sys

ProcTable.ps{ |process| p process.ppid }
 
> The dynamic loading of functions under x64 platforms is 
> though, but could work around it (also, waiting for my OEM 
> Vista to arrive... damn postal parcels!)
With sys-proctable, you needn''t worry about such things.
> The funny thing is "So long as the WMI service is running" ;-)
Well, it''s enabled by default. So, unless someone goes in and turns it
off, it''s running.
 
> Also, I dropped win32-service support on previous releases 
> for a native, compiled implementation that don''t hook or 
> crash the RubyVM used by Mongrel. Which worked better, until 
> users start jumping to x64 platforms ;-)
Hm, I really need to revisit win32-service. The whole VC 6 vs VC 8 issue
has proven to be annoying.

Regards,

Dan


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.

On 4/2/07, Berger, Daniel <Daniel.Berger at qwest.com>
wrote:
> > -----Original Message-----
> > From: mongrel-users-bounces at rubyforge.org
> > [mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Luis
Lavena
> > Sent: Monday, April 02, 2007 1:26 PM
> > To: mongrel-users at rubyforge.org
> > Subject: Re: [Mongrel] mongrel_service fails to get
> > "service.exe" from ppid?
> >
> >
> > On 4/2/07, Berger, Daniel <Daniel.Berger at qwest.com> wrote:
> > > <snip>
> > >
> > > > Maybe I could code some dynamic loading (like psapi in
> > > > proc_info) to workaround this case scenario.
> > > >
> > > > Please let me know the results.
> > >
> > > Are you just trying to get process information? The sys-proctable
> > > package works on MS Windows. I dropped the psapi approach a
> > long time
> > > ago in favor of OLE + WMI. So long as the WMI service is
> > running, it
> > > should work on any Windows platform.
> > >
> >
> > Thanks Dan for the information, but OLE + WMI is overkill for
> > the task. Since I support XP, 2003 and Vista on 32bits
> > platforms, using psapi way is what I wanted.
>
> Overkill? It''s abstracted away for you:
>
> require ''sys/proctable''
> include Sys
>
> ProcTable.ps{ |process| p process.ppid }
>
Overkill since I no longer use win32-service nor a ruby process as
service, but a stub native service utility that spawn the ruby process
with mongrel.
>[...]
>
> > Also, I dropped win32-service support on previous releases
> > for a native, compiled implementation that don''t hook or
> > crash the RubyVM used by Mongrel. Which worked better, until
> > users start jumping to x64 platforms ;-)
>
> Hm, I really need to revisit win32-service. The whole VC 6 vs VC 8 issue
> has proven to be annoying.
>
As I said previously and a few months back, ruby + green_threads +
sockets + rails + win32 != stable solution.

The most stable and gracefully stoppable I got was using a compiled
service and leave ruby just for mongrel.

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

On 4/2/07, Berger, Daniel <Daniel.Berger at qwest.com>
wrote:
> [...]
>
> > Also, I dropped win32-service support on previous releases
> > for a native, compiled implementation that don''t hook or
> > crash the RubyVM used by Mongrel. Which worked better, until
> > users start jumping to x64 platforms ;-)
>
> Hm, I really need to revisit win32-service. The whole VC 6 vs VC 8 issue
> has proven to be annoying.
I have started using Windows SDK Update for Vista [1] which sport VC8
sp1, Platform SDK headers + MSDN help, using just 500MB of HDD. This
is the same compiler used by Visual Studio, and most important is
*free*

I''m trying to get everything setup and drop VC6 for good sake, even if
I have to recompile every extension available.

Maybe we could talk about this off the list if you''re interested?

[1]
http://www.microsoft.com/downloads/details.aspx?FamilyID=ff6467e6-5bba-4bf5-b562-9199be864d29&displaylang=en

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

> Maybe I could code some dynamic loading (like psapi in proc_info) to
> workaround this case scenario.
>
> Please let me know the results.
WinXP x64
 *** CURRENT PROCESS ***
 EnumProcessModules (PID, name): 2020      proc_info.exe
 Module32First (PID, name): 2020           proc_info.exe
 GetProcessImageFileName (PID, name): 2020
\Device\HarddiskVolume1\Documents and
Settings\Administrator\desktop\proc_info_3\proc_info.exe

 *** PARENT PROCESS ***
 EnumProcessModules (PID, name): 2416      <unknown>
 Module32First (PID, name): 2416           Error Creating Snap (SNAPMODULE)
 GetLastError: 299Only part of a ReadProcessMemory or
WriteProcessMemory request was completed.
 <unknown>
 GetProcessImageFileName (PID, name): 2416
\Device\HarddiskVolume1\WINDOWS\system32\cmd.exe



Win2003 x64
 *** CURRENT PROCESS ***
 EnumProcessModules (PID, name): 1856      proc_info.exe
 Module32First (PID, name): 1856           proc_info.exe
 GetProcessImageFileName (PID, name): 1856
\Device\HarddiskVolume2\Documents and
Settings\VMWServ\desktop\proc_info_3\proc_info.exe

 *** PARENT PROCESS ***
 EnumProcessModules (PID, name): 1584      <unknown>
 Module32First (PID, name): 1584           Error Creating Snap (SNAPMODULE)
 GetLastError: 299Only part of a ReadProcessMemory or
WriteProcessMemory request was completed.
 <unknown>
 GetProcessImageFileName (PID, name): 1584
\Device\HarddiskVolume2\WINDOWS\system32\cmd.exe



Woot!

I''m happy if this would help even a little.

On 4/3/07, blindance at gmail.com <blindance at gmail.com>
wrote:
> > Maybe I could code some dynamic loading (like psapi in proc_info) to
> > workaround this case scenario.
> >
> > Please let me know the results.
>
> WinXP x64
>  *** CURRENT PROCESS ***
>  EnumProcessModules (PID, name): 2020      proc_info.exe
>  Module32First (PID, name): 2020           proc_info.exe
>  GetProcessImageFileName (PID, name): 2020
> \Device\HarddiskVolume1\Documents and
> Settings\Administrator\desktop\proc_info_3\proc_info.exe
>
>  *** PARENT PROCESS ***
>  EnumProcessModules (PID, name): 2416      <unknown>
>  Module32First (PID, name): 2416           Error Creating Snap (SNAPMODULE)
>  GetLastError: 299Only part of a ReadProcessMemory or
> WriteProcessMemory request was completed.
>  <unknown>
>  GetProcessImageFileName (PID, name): 2416
> \Device\HarddiskVolume1\WINDOWS\system32\cmd.exe
>
>
>
> Win2003 x64
>  *** CURRENT PROCESS ***
>  EnumProcessModules (PID, name): 1856      proc_info.exe
>  Module32First (PID, name): 1856           proc_info.exe
>  GetProcessImageFileName (PID, name): 1856
> \Device\HarddiskVolume2\Documents and
> Settings\VMWServ\desktop\proc_info_3\proc_info.exe
>
>  *** PARENT PROCESS ***
>  EnumProcessModules (PID, name): 1584      <unknown>
>  Module32First (PID, name): 1584           Error Creating Snap (SNAPMODULE)
>  GetLastError: 299Only part of a ReadProcessMemory or
> WriteProcessMemory request was completed.
>  <unknown>
>  GetProcessImageFileName (PID, name): 1584
> \Device\HarddiskVolume2\WINDOWS\system32\cmd.exe
>
>
>
> Woot!
>
> I''m happy if this would help even a little.

Yeah, I''m happy too!

It seems that ReadProcessMemory (which is called from Module32First
API), fail to get information from 64-bits parent process.

I''ll like to know from Vista users that hang on the list about their
results too, since WinAPI is always a pain to get working on different
platforms.

Anyway, based on these results I''ll patch ServiceFB and prepare a
pre-release of mongrel_service with logging capabilities too (which is
waiting in my out-box to be commited).

Thanks for your help and feedback.

Later,

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

>I''ll like to know from Vista users that hang on the list about
their
>results too, since WinAPI is always a pain to get working on different
>platforms.
okay, results are;


Vista64:
 *** CURRENT PROCESS ***
 EnumProcessModules (PID, name): 1844      proc_info.exe
 Module32First (PID, name): 1844           proc_info.exe
 GetProcessImageFileName (PID, name): 1844
\Device\HarddiskVolume1\Users\fukuoka\Desktop\proc_info_3\proc_info.exe

 *** PARENT PROCESS ***
 EnumProcessModules (PID, name): 1968      <unknown>
 Module32First (PID, name): 1968           Error Creating Snap (SNAPMODULE)
 GetLastError: 299Only part of a ReadProcessMemory or
WriteProcessMemory request was completed.
 <unknown>
 GetProcessImageFileName (PID, name): 1968
\Device\HarddiskVolume1\Windows\System32\cmd.exe



Vista32:
 *** CURRENT PROCESS ***
 EnumProcessModules (PID, name): 1468      proc_info.exe
 Module32First (PID, name): 1468           proc_info.exe
 GetProcessImageFileName (PID, name): 1468
\Device\HarddiskVolume1\Users\test\Desktop\proc_info_3\proc_info.exe

 *** PARENT PROCESS ***
 EnumProcessModules (PID, name): 3944      cmd.exe
 Module32First (PID, name): 3944           cmd.exe
 GetProcessImageFileName (PID, name): 3944
\Device\HarddiskVolume1\Windows\System32\cmd.exe

On 4/5/07, blindance at gmail.com <blindance at gmail.com>
wrote:
> >I''ll like to know from Vista users that hang on the list about
their
> >results too, since WinAPI is always a pain to get working on different
> >platforms.
>
> okay, results are;
>
>
> Vista64:
>  *** CURRENT PROCESS ***
>  EnumProcessModules (PID, name): 1844      proc_info.exe
>  Module32First (PID, name): 1844           proc_info.exe
>  GetProcessImageFileName (PID, name): 1844
> \Device\HarddiskVolume1\Users\fukuoka\Desktop\proc_info_3\proc_info.exe
>
>  *** PARENT PROCESS ***
>  EnumProcessModules (PID, name): 1968      <unknown>
>  Module32First (PID, name): 1968           Error Creating Snap (SNAPMODULE)
>  GetLastError: 299Only part of a ReadProcessMemory or
> WriteProcessMemory request was completed.
>  <unknown>
>  GetProcessImageFileName (PID, name): 1968
> \Device\HarddiskVolume1\Windows\System32\cmd.exe
>
>
>
> Vista32:
>  *** CURRENT PROCESS ***
>  EnumProcessModules (PID, name): 1468      proc_info.exe
>  Module32First (PID, name): 1468           proc_info.exe
>  GetProcessImageFileName (PID, name): 1468
> \Device\HarddiskVolume1\Users\test\Desktop\proc_info_3\proc_info.exe
>
>  *** PARENT PROCESS ***
>  EnumProcessModules (PID, name): 3944      cmd.exe
>  Module32First (PID, name): 3944           cmd.exe
>  GetProcessImageFileName (PID, name): 3944
> \Device\HarddiskVolume1\Windows\System32\cmd.exe

Perfect!, that means the API is forward compatible.

Ok, will patch mongrel tonight and do a pre-release tomorrow morning.

Thank you guys for testing and providing feedback.

Regards,

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi