Doesn't start if running from a network share

[lio972]

Doesn't start if running from a network share

[GoogleCodeExporter]

How are you launching PeerBlock - double-clicked on the .exe file, or through a 
shortcut?  If a shortcut, did you make sure to set the "Working Dir"/"Start In" 
field correctly?  Is the network share mapped to a drive-letter, or are you 
accessing it via UNC path (e.g. "\\myserver\network_share\peerblock\")?

Out of curiosity, did PG2 ever run successfully this way?  Off the top of my 
head I 
can't think of anything we've changed that could cause this problem in 
PeerBlock but 
not the base PG2 code...

Original comment by [email protected] on 10 Aug 2009 at 8:43

[GoogleCodeExporter]

i double clicked the .exe

btw, should there be a service services.msc?

nope, i never tried PG2 on this system

although crashing on start, PB crashes the box after some minutes (it's 
headless, so
sorry, no information about how it crashes, i suspect a memory leak, the box is 
ultra
low spec with 256 mb ram).

i'll try again with another build. 

is there a way to specify a data directory. this way i could try to install it 
to c:

Original comment by [email protected] on 10 Aug 2009 at 8:58

[GoogleCodeExporter]

Was the network-share mapped to a drive-letter?

Sadly, we don't run as a Windows Service right now.  That's one of my goals 
(Bug#3),
but isn't likely to happen for a long while due to the amount of code changes
required.  Rumor has it that with some hackery people were able to get PG2 
running as
a service, might be worth drudging through the PG2 forums/wiki to see if you 
can find
more info there.

Creating an option to specify a data directory is a great idea.  Currently the
original PG2 stuff is I believe based on the .exe's location, while the
PeerBlock-specific additions (peerblock.log, .dmp) are based on the program's
"Working Directory" (i.e. the "Start In" dir for shortcuts).

Original comment by [email protected] on 10 Aug 2009 at 9:31

[GoogleCodeExporter]

yes, the share was mapped to M:

i really wonder why, after PB appearently didn't start, it crashed the whole 
machine
minutes later.. strange things..

Original comment by [email protected] on 11 Aug 2009 at 7:11

[GoogleCodeExporter]

Hmm, it's VERY strange that this problem could cause PeerBlock to crash the 
system. 
Since we couldn't find the driver, we couldn't load it.  And this driver is the 
only
portion of PeerBlock running in the kernel, so should be the only part of the 
program
that could have a chance at crashing the box.  Unless it's exposing a problem 
in some
other kernel-mode component on the system, the OS-crash may be a coincidence... 
 Does
that reproducibly happen?

Original comment by [email protected] on 12 Aug 2009 at 10:36

[GoogleCodeExporter]

yes, it happend always until i deinstalled PB

Original comment by [email protected] on 13 Aug 2009 at 8:09

[GoogleCodeExporter]

I'm out-of-town this week, but will try reproducing this problem when I get 
home this
weekend.

Original comment by [email protected] on 13 Aug 2009 at 2:38

[GoogleCodeExporter]

On Win7 x64 (RC1), I'm able to reproduce I believe this same problem with the
following steps:

1. Share a directory on the local machine, e.g. called "peerblock", assigning
"Everyone" permissions of Read/Change.

2. From Windows Explorer, open e.g. "\\<machine-name>\peerblock"

3. Double-click on peerblock.exe to launch.

Following this repro-case, I get a similar error, though this time with
StartService/123/"The filename, directory name, or volume label syntax is 
incorrect".
 I'm assuming that whatever the root cause of this, they've changed simply the error
code that shows up in Win7 versus XP.

Same symptom (StartService/123) when mounting a directory via command line 
("pushd
\\<machine-name>\peerblock").

No OS crash though, at least not yet.  Only ~4MB allocated, so not much of an
opportunity to leak memory...

Any chance you could upload your os-crash .dmp for at least a quick triage?

Original comment by [email protected] on 16 Aug 2009 at 4:47

• Changed state: Accepted

[GoogleCodeExporter]

Updating description so it's more easily identifiable on the main buglist 
screen.

Haven't had a chance to look into this yet, though.  Should probably retest 
with the
new path-logging code we have in there, see if we can identify a problem with 
the
pathname we're trying to load - we might need to use a different routine to load
files off shares (even those mapped to local drives), potentially even copying 
the
driver to the local %temp% directory prior to loading it if nothing else 
works...

Original comment by [email protected] on 8 Sep 2009 at 11:51

• Changed title: Doesn't start if running from a network share

[GoogleCodeExporter]

Hi...I am having this error and I am not running a network share. The error 
happens
when I exit PeerBlock and try to start it again. The only way to get it running 
again
is with a reboot.

I am using PeerBlock version 0.9.2 (r86)with Windows XP Pro SP3.

I am starting PeerBlock with the desktop icon.

Any ideas?

Original comment by [email protected] on 21 Sep 2009 at 4:20

[GoogleCodeExporter]

If you could upgrade to r162
(http://devblog.peerblock.com/2009/09/peerblock-r162-interim-release-now-with.ht
ml),
reproduce the problem, and post your peerblock.log that would be helpful.  
There is
some additional information in post-r86 Interim Releases that should help us 
figure
out what's going on.

Thanks!

Original comment by [email protected] on 22 Sep 2009 at 1:14

[GoogleCodeExporter]

Hi,

Upgraded to PeerBlock-Setup_v1.0.0.r181. I have similar behavior. Attached is my
peerblock.log

Original comment by [email protected] on 28 Sep 2009 at 9:57

Attachments:

• peerblock.log

[GoogleCodeExporter]

scottmsanders, are you sure you were running PeerBlock from a network share?  
Looking
at your logfiles it looks like you were running it from your local machine; 
also, the
error message you were getting looks slightly different (CreateFile instead of
StartService).  I'm thinking you're experiencing the other issue you posted your
logfiles to, Issue #80, and not this one.

Either way, I'm targetting this one for 1.1

Original comment by [email protected] on 29 Sep 2009 at 4:08

• Added labels: Milestone-Release1.1

[GoogleCodeExporter]

Hi...I do not have any network shares that I use or know of. Attached is a 
screenshot
of a command prompt using the command "net share".

I did a search of the error I had...and found it here, and in Issue 80. I was 
unsure
where to post my info...so I posted in both places.

Scott

Original comment by [email protected] on 29 Sep 2009 at 5:10

Attachments:

• share.doc

[GoogleCodeExporter]

Original comment by [email protected] on 30 Sep 2009 at 4:20

• Added labels: Milestone-1.1
• Removed labels: Milestone-Release1.1

[GoogleCodeExporter]

Okay, thanks for the update scottmsanders.  I think Issue #80 is the one you'll 
want
to follow.  Just didn't want you to get confused if for example we were to fix 
this
bug but your problem still exists!

Original comment by [email protected] on 3 Oct 2009 at 6:37

[GoogleCodeExporter]

After looking further into this, it appears as though Windows won't allow you to
start a service that resides on a network share.  Since this is how we 
interface with
our driver, this is an issue for us.  The only way we'd be able to work around 
this
would be to copy the driver over from the network share to a local disk, then 
load
the driver from there, then delete it once we're done.

Would someone who's interested in this bug mind commenting as to whether this 
sort of
a workaround would be of interest to them?

Original comment by [email protected] on 10 Oct 2009 at 5:28

[GoogleCodeExporter]

This would be the perfect workaround for me. Please make the local path 
adjustabel.

Original comment by [email protected] on 10 Oct 2009 at 7:02

[GoogleCodeExporter]

this would be the perfect solution for me. please make the local path 
adjustable.

Original comment by [email protected] on 10 Oct 2009 at 8:26

[GoogleCodeExporter]

Don't think we're going to get to this in the 1.1 timeframe, so letting it slip 
to
1.2 instead.

Original comment by [email protected] on 30 Mar 2010 at 4:27

• Added labels: Milestone-1.2
• Removed labels: Milestone-1.1