BC2 not starting on Windows 7 x64

[Former user]

On my updated w7 box x64 the program isn't starting at all. I'm not even seeing a short process popping up in process hacker. What can I do for further investigation, is there any debug/logging function?

[guy]

1. Make sure .NET is up to date. It probably is since you just updated your box.
2. There aren't any debug commands (yet) outside of running the source code. You could try to go straight to settings with --settings and see if that works.
3. The application needs to write to your %appdata% folder and may be blocked.

What, if any, AV are you using? It could also be blocking BC2 because it has embded .dll files in it.

[guy]

Here is a test version that includes some logging. this version does not have automatic updates enabled. https://browserchooser2.com/app/27/Browser%20Chooser%202.exe

Turn on logging with --log

It will create a file called bc2.log in the same folder from where you run the application. While this log, I will get a better idea of what is going wrong.

[phk]

Hey, sorry for the delay.

Trying the previous version with the suggested --settings flag didn't do anything. When I tried your logenabled version, the execution looked like it took about 3 seconds, so I thought there was some log written, but it doesn't. Examining it with process hacker didn't show up anything process like, even for a short time, too. If opening a log file is the first thing it does, maybe it's not coming up even to this part.

Installed .NET Framework is 4.7 and I have loads of different vc++redist versions installed too, could something conflict it?

I'm open for directions where to look further, on Windows 10 on the same box (multiboot) it worked but I'm not using this.

cheers phk

[guy]

That is weird. It must be crashing very early in the process. only about 7 steps are taken before the logs start to be written.

Redownload the file https://browserchooser2.com/app/27/Browser%20Chooser%202.exe

This version has logging forced enabled and starts to write immediately, long before it can see the --log option.

[phk]

Hey, again sorry for the late reply.

I had some time to look further into this issue and i'm not really understanding what happens. The log enforced version did not pruduce any logs so I hooked the process up to sysinternals procmon but the only thing I see is that it tries to open a "browser chooser 2.pdb" debug file from different places, then it stops suddenly. I dumped all relevant things like threads, reg, and file stuff so you can filter on demand.

Hopefully this will help to solve this strange riddle ;)

No attachments here so I uploaded it to owncloud: https://phk.querbass.de/index.php/s/wl5dYhlVuUwv7lz

So thanks and some relaxed christmas holidays, I will be at 34C3 so I will respond a little bit later

cheers phk

[phk]

Ah and forgot to mention, I'm using ESET but I tried disabling it already, it produces the same 1536 event output on procmon

[guy]

I am not too sure what is happening. It looks like its looking for something.

I've uploaded the pdb file here: https://browserchooser2.com/app/27/Browser%20Chooser%202.pdb

Hopefully this can provide more information.

[guy]

Looks like I made a mistake with the logger. Can you redownload the file above and see if it generates a log. The old one would try to write to system32 - which it can't

[phk]

No luck with the updated version (no log) and the pdb file, but i had no time to look further into procmon dump.

I tried something different and logged into the Administrator account, which worked an program starts and produces a log.

So I'm thinking the program has either a problem with my username, which contains unicode characters, or with redirected paths for system & user tempfiles on another drive.

As both are known to cause problems with some programs, maybe you could check this?

[guy]

Those make sense. I think it may have to do more with the username since I don't use temp files. I will have to setup a VM to test it.

[phk]

for testing purpose, the possible problematic character in my username is: ³

[guy]

I just tried with a user name of Test³ and it worked as expected. The way I write the char is ALT+0179. Is this the same way for you?

[guy]

Oh shoot, I just saw your still on Win7. Time for a new VM.

Also, if you quickly on hand how you did the redirects, I will test it out in my VMs.

[phk]

For the key, I used the right alt (alt gr on german layout) and the normal 3 key in combination, the same way you would enter "mathematical ^2 or times 2" I think it's called in english (but twice in my user name so it's ³³), I'm not sure what you mean with ALT+0179, I guess you enter the ansi character this way, try the usual keyboard instead.

The redirection is done using environment variables via advanced system preferences settings, redirected to another physical hard drive, as I don't want these writes on my ssd.

There are some other redirects done using NTFS junction points, which should NOT be the cause in your case, as these are used for specific application environments. But for completeness: You can use some sort of likewise symlinks, known to the unix world, but with windows board utilities like:

mklink /J "C:\Link" "D:\Target"

This works across filesystem boundaries and physical drives, like symlinks do. Hope this helps

[guy]

At this point, I am sure it's the temp folder. I was able to break BC2 but am not sure how to fix it yet. The problem comes when I try to read the settings file. I use XMLSerializer and it needs to write to temp. There is another piece of code that extracts embedded DLLs and it may need to write to temp as well. I can only get the error if I write-protect the folder, it's not quite your situation.

[phk]

Maybe it's worth the note, all 4 temp folders are redirected exactly like this:

user tmp & user temp both redirected to e:\TEMPFILES#USERTEMP using advanced system settings

windows systemwide tmp & temp redirected to E:\TEMPFILES#WINTEMP but here I was using junction points, just rechecked this, so my last post was not true for the systemwide tempfiles, my mistake, I'm sorry.

[guy]

I think I found a way around the problem with minimal code changes.

Can you retry https://browserchooser2.com/app/27/Browser%20Chooser%202.exe

this version extracts an extra file that is used during the loading. It should avoid trying to write to temp.

[guy]

Fixed in Release 2, out now.

[phk]

Unfortunately the problems still persists in the latest 2.0.3.27397 version, but due to lack of time, I'm currently unable to look further into it. Maybe later, I would then come back to you.

Thanks for the effort, best wishes -phk