François
This could sound silly.. but is your Firewall active?
We have a service application that receives UDP packets and we only have
issues when windows firewall is active
Eric
-Mensagem Original-
From: Francois PIETTE
Sent: Monday, April 18, 2011 4:47 AM
To:
Francois PIETTE wrote:
GDisplayProc is assigned a routine which output the message to the
console window and to the log file and which is used all over the
application.
Guess what ? It works !
This is not satisfying since the log file is full of unwanted
messages and this probably only
Surely, an attached debugger is going to use some CPU time, however
small even if nothing triggers it, therefore, the debugged program cycle
timing will change somehow, however small.
Plus, however the debugger works, it could be forcing some other process
(in the kernel) to do it's job more
GDisplayProc is assigned a routine which output the message to the
console window and to the log file and which is used all over the
application.
Guess what ? It works !
This is not satisfying since the log file is full of unwanted
messages and this probably only hides the real problem.
Does
Francois PIETTE wrote:
GDisplayProc is assigned a routine which output the message to the
console window and to the log file and which is used all over the
application.
Guess what ? It works !
This is not satisfying since the log file is full of unwanted
messages and this probably only
While testing, I also had during some time FD_READ triggered but
ReceiveFrom returning -1.
Isn't that quite common, if those are WSAEWOULDBLOCK errors?
As far as I know, not so much. I saw is returning -1 during 4 seconds which
is the timeout time in my appication.
--
Hello Francois,
Hi !
I have a strange problem: in a windows service and using UDP, the
service do not receive UDP datagram. Trying to debug this problem, I
attach Delphi debugger to the running service and suddenly it starts
receiving the UDP datagrams !
Actually the service is a dual
No idea, but that can't be a permission issue IMO. Receiving datagrams
in a service running as system works fine. Also attaching a debugger
doesn't change security context of the debugee.
What happens is that a new thread is created in the process being
debugged, maybe there's some issue with
On 18/4/2011 2:34 μμ, Francois PIETTE wrote:
No idea, but that can't be a permission issue IMO. Receiving datagrams
in a service running as system works fine. Also attaching a debugger
doesn't change security context of the debugee.
What happens is that a new thread is created in the process
I had a similar experience in the past, not with ICS components but
generally working on a completely different project.
When project was running normally at some point did not work but when
attaching a debugger then it would work.
The problem at that situation was that the program needed some
*Subject:* Re: [twsocket] UDP receive issue from a Windows service
The code for the service is the code I already used in other
application which works fine (using TCP altough).
I have UDP listen sockets in my ComCap application, running as a service,
sucking in syslogs on port 514 24/7 from
Maybe when you use the debugger then the application run undeer a different
user?
Bye, Maurizio.
This mail has been sent using Alpikom webmail system
http://www.alpikom.it
--
To unsubscribe or change your settings for TWSocket mailing list
Maurizio Lotauro wrote:
Maybe when you use the debugger then the application run undeer a
different user?
Not when the debugger is attached to a running process.
If the debugger spawns the process to be debugged with CreateProcess
then that might happen.
--
Arno Garrels
--
To unsubscribe or
On 18/4/2011 5:12 μμ, Arno Garrels wrote:
Maurizio Lotauro wrote:
Maybe when you use the debugger then the application run undeer a
different user?
Not when the debugger is attached to a running process.
If the debugger spawns the process to be debugged with CreateProcess
then that might
Maybe when you use the debugger then the application run
undeer a different user?
I start the service which starts sending his UDP datagrams (This is a SNMP
client) and waiting for UDP response which never comes. Then I attach the
debugger to the running service process and suddenly the UDP
I think that if you consider what I suggested before, might help you...
It maybe has to do with extra process time the debugger gives
Thanks for insisting.
Which extra process time do you mean ? The debugger has just to be attached.
No need to set any breakpoint nor single step. Just attach.
On 18/4/2011 5:35 μμ, Francois PIETTE wrote:
I think that if you consider what I suggested before, might help you...
It maybe has to do with extra process time the debugger gives
Thanks for insisting.
Which extra process time do you mean ? The debugger has just to be
attached. No need to set
When the debugger is attached is it exactly the same like when it's not
attached for the program being executed ?
I would say no since my application is working.
But I would say it doesn't change the time required to do domething.
OK then, my idea was that it's different.
Actually I work with
Francois PIETTE wrote:
Maybe when you use the debugger then the application run
undeer a different user?
I start the service which starts sending his UDP datagrams (This is a
SNMP client) and waiting for UDP response which never comes. Then I
attach the debugger to the running service
Arno Garrels wrote:
Francois PIETTE wrote:
Maybe when you use the debugger then the application run
undeer a different user?
I start the service which starts sending his UDP datagrams (This is a
SNMP client) and waiting for UDP response which never comes. Then I
attach the debugger to the
Hi Francois,
Actually the service is a dual mode service/app console and it works
perfectly well as a console application (and also as a service when a
debugger is attached).
I do not understand the 'dual mode' but could that be a reason? What happens
if you put your application into 1 object
Actually the service is a dual mode service/app console and it works
perfectly well as a console application (and also as a service when a
debugger is attached).
I do not understand the 'dual mode' but could that be a reason?
A dual mode service is an application which detect if it run as a
Hi Francois,
A dual mode service is an application which detect if it run as a
service
I understeand. I did the same concept years ago
--
mvg, Wilfried
http://www.mestdagh.biz
http://www.comfortsoftware.be
http://www.expertsoftware.be
--
To unsubscribe or change your settings for TWSocket
23 matches
Mail list logo
