About software, technology and random things


High DPI / Font Scaling Display Problem With LibreOffice


When I installed LibreOffice on my Windows 10 notebook with 125% font scaling, I immediately noticed that the menu bar was somehow hiding behind the title bar and everything I clicked was recognized as clicked a couple dozen pixels above what I was actually pointing at.

This seems to be a known problem for LibreOffice with OpenGL and high DPI / high font scaling, maybe specifically in conjunction with my Intel HD Graphics / IGPU.

The fix is fairly easy but difficult to find out on your own:

  1. Make sure that no LibreOffice application is running.
  2. Open the LibreOffice OpenGL blacklist configuration file with a text editor, usually found at C:\Program Files\LibreOffice 5\share\opengl\opengl_blacklist_windows.xml.
  3. Inside the block enclosed by the <blacklist> tag, add the following block:
    <entry os="all" vendor="intel">
        <device id="all"/>
  4. Save and start a LibreOffice application to check.

This should do it!

Thanks for reading!



Open PhpStorm From Windows Explorer Context Menu For Directories


If you are a bit lazy like me and just want to simply open PhpStorm from the directory that you've currently navigated to in Windows Explorer, you can use this .reg file to add the registry entries for the entry in the context menu.

Warning: This involves messing around a bit with the registry. Please make sure you understand what you are doing!

This .reg file assumes that the path to your PhpStorm installation is C:\Program Files (x86)\JetBrains\PhpStorm 2017\. If it is not, just search and replace every occurrence of the path in the .reg file with the one that applies for you. Remember to escape backslashes with a backslash!

Windows Registry Editor Version 5.00


@="Open Directory in PhpStorm"
"Icon"="C:\\Program Files (x86)\\JetBrains\\PhpStorm 2017\\bin\\phpstorm64.exe"

@="C:\\Program Files (x86)\\JetBrains\\PhpStorm 2017\\bin\\phpstorm64.exe \"%1\""

@="Open Directory in PhpStorm"
"Icon"="C:\\Program Files (x86)\\JetBrains\\PhpStorm 2017\\bin\\phpstorm64.exe"

@="C:\\Program Files (x86)\\JetBrains\\PhpStorm 2017\\bin\\phpstorm64.exe \"%1\""

@="Open Directory in PhpStorm"
"Icon"="C:\\Program Files (x86)\\JetBrains\\PhpStorm 2017\\bin\\phpstorm64.exe"

@="C:\\Program Files (x86)\\JetBrains\\PhpStorm 2017\\bin\\phpstorm64.exe \"%V\""

Instructions: Just copy the text into a text file, save it as a file with the .reg extension (e.g. "phpstorm.reg") and execute it via double-click. When asked if you want to continue modifying the registry, confirm with "Yes".

Note: You might wonder why the registry paths contain a segment called "Aphpstorm" instead of "phpstorm" (or anything else). This is so that this entry takes alphabetic precedence over other entries and it is sorted further up. It will not influence the text displayed in the context menu.

Unfortunately I do not know the exact source for this neat little trick because I got this from a colleague at work.

If you wish to revert these changes at some point, just do what the first three instructions in the .reg file do: delete the 3 appropriate keys in the registry.

I hope this is useful to you! It sure is for me.

Thanks for reading!


Using msysgit With PuTTY Pageant & Plink


If you have installed msysgit and are planning on using it in combination with Pageant from the PuTTY tool suite, you might run into the problem that it does not attempt to use any of the keys you have already loaded into Pageant. You can fix this by telling msysgit which program to use for the git fetch and pull operations:

  • Open your System window (Windows + Pause or "Start" => Right-click on "Computer" => "Properties")
  • Click on "Advanced system settings" (on the left)
  • Click on "Environment Variables..." (on the bottom)
  • Add a new system variable (or user variable if you just want this setting for the current user): "New..."
  • Variable name: GIT_SSH
    Variable value: (path to plink.exe) for example: C:\Program Files (x86)\PuTTY\plink.exe (important: just the path, no quotation marks at the beginning or the end!)
  • If you haven't already on this system / user, connect to the server via PuTTY in order to get the SSH server fingerprint prompt and remember it
  • Close any existing Git Bash / msysgit instances and start it up again

This should do it!

I hope this was helpful.

Thanks for reading!



Deleting Huge Directories in Windows Via Command Prompt


If you'd like to delete a huge folder / directory in Windows with maybe thousands or hundreds of thousands of files inside, doing that via Explorer might cost you a lot more time than via command prompt.

Here's how to do it faster:

  1. Open the command prompt by using "Start" => "cmd" and navigating to the desired path via "cd <path>" or "pushd <path>"
    - OR -
    navigate to the folder in the Explorer and use Shift + right-click and "Open command window here"
    (Note: if deleting the desired folder requires elevated privileges, you will have to start a command prompt in elevated mode and navigate the old-fashioned way)
  2. Use the following command:
    rmdir /s /q folder

A little explanation about rmdir's flags:

  • /s: removes the directory itself including all the contained files and subdirectories
  • /q: forces deletion and does not ask for approval

Doing this can be very helpful in a coding environment where you can easily end up with thousands of small files.

Thanks for reading!



Viewing Hidden Devices in Windows Device Manager


If you are trying to find a device that has been hidden in your Windows Device Manager, for example because you don't have it plugged in at the moment, you might find this little guide handy.

  1. Open the command prompt ("Start" => "cmd")
  2. Enter
    set devmgr_show_nonpresent_devices=1
  3. Then start the Device Manager from the command prompt via
  4. In the Device Manager, click "View" => "Show hidden devices"

I hope this helped 🙂

Thanks for reading!



Installing the Logitech F710 Wireless Gamepad on Windows 7 x64 (XInput Driver)

Update from 2015-10-18: Windows 10 Pro (x64) does not appear to require this workaround. It automatically installed the correct driver and allowed me to use the controller right away.


In order to be able to benefit from using the XInput mode for the Logitech F710 Wireless Gamepad, of course you need to install the correct driver. This is made a little hard for Windows 7 x64 seeing as there is no driver that comes with the device itself.

I found a guide on how you can manage it by using Microsoft's official Xbox 360 Controller driver.

Be careful though, you're messing with driver files. Use this guide at your own risk.

  1. Go to the Microsoft Hardware downloads page:
  2. Click on the category "Gaming"
  3. Click on the link "Xbox 360 Wireless Controller for Windows"
  4. Download the correct version of the file (Windows 7 64-bit only) and install it
  5. Open the Device Manager (e.g. [Windows]+[Break] => Device Manager)
  6. Right-click on the entry with "Logitech F710" in its name and the yellow triangle icon in front of it
  7. Open its properties
  8. Switch to the "Details" tab
  9. Choose the property "Hardware Ids"
  10. Right-click on the one without the "&REV_<Number>" at the end of the name and copy it. It should look something like this: USB\VID_046D&PID_C21F
  11. Go to the directory in which you installed the Xbox 360 Accessories Software a minute ago: C:\Program Files\Microsoft Xbox 360 Accessories
  12. Open the file Xusb21.inf with a plain text editor like Notepad
  13. At the top in the commented section you can see the line containing "Wireless Common Controller USB\Vid_045E&Pid_0719". Search for "USB\Vid_045E&Pid_0719" and replace each occurence with the hardware ID you copied earlier. Afterwards, save it to the file. You might need to have your editor program in elevated privilege mode in order to do so.
  14. Go back to the Device Manager with the open F710 properties window
  15. Switch to the "Driver" tab
  16. Click on the "Update Driver..." button
  17. In the assistant, choose "Browse my computer for driver software"
  18. Choose the path "C:\Program Files\Microsoft Xbox 360 Accessories"
  19. Confirm the driver warning and you're good to go

To check if it really worked, you can just press the Logitech button on the game controller and it should cause a little frame with the Xbox logo, the text "Click for Help" and a down-pointing arrow button and an X button to pop up in the lower center of your screen.

I do not usually recommend modifying driver files like that, but I have used this method before and it worked for me, so I stopped looking for a better way, as there doesn't seem to be any official solution provided by Logitech themselves (which is a shame).

Original post and the ones who can be credited with this solution: post by breakfastmonkey on the official Logitech forums (referencing a couple of previous posts in the same thread).

Thanks for reading.


Making Traceroutes Work with a Firewall (Windows)


Even though I've had software firewalls in action for years now, I haven't really come across too many instances where I'd need traceroutes. The few times I did, however, I noticed that I only got output like the following:


Tracing route to []
over a maximum of 30 hops:

  1     *        *        *     Request timed out.
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9     *        *        *     Request timed out.
 10     *        *        *     Request timed out.
 11    50 ms    50 ms    50 ms []

Trace complete.

The number of hops would of course vary for the specific host / IP address.

Today I had to use traceroute in order to analyze a couple of networking problems. That was the incentive I needed to look up why it didn't work.

The fact that not even my router was showing up was a big indicator that something was wrong with my local firewall settings.

After searching the web for a couple of minutes, I found out what I was looking for at this page:

Traceroute is using ICMP packets (plus UDP on Linux systems, but that's outside the scope of this blog entry. You can read more about it on the page I linked above). But even for an outgoing traceroute you need to accept incoming ICMP packets.

Which ones? These:

  • ICMP TTL Expired (Type 11, Code 0)
  • ICMP Port Unreachable (Type 3, Code 3)

Once you've enabled these types of packets for incoming traffic in your firewall(s), you'll see that your traceroute will now function as it should.

If your firewall does not allow you to configure accepting specific types of ICMP packets, try allowing incoming ICMP packets altogether (if that's not too much of a compromise for you).

Anyway, long-ish story short: It's working now 🙂

Thanks to the webmaster of the page I linked above! And thanks to you for reading.


Adobe Premiere Pro CS5 and the Long Loading Splash


If you have used Adobe Premiere Pro CS5 (or several other CS5 products as I've read), you might have encountered long waiting times during the program launching. In the case of Premiere Pro CS5, the splash screen shows "Loading ExporterQuickTimeHost.prm" and sticks with it for a couple of minutes (yes, minutes). This is not even a one-time thing or a once-per-Windows-session, it happens each and every program launch.

When I researched this, I quickly found the answer in Adobe's forums: Premiere CS5 takes 5 minutes to start up

In fact, what's causing this is not just the Adobe program, but rather the combination of a firewall and the Adobe program. If you are as restrictive in terms of Internet access as I am, you might have forbidden Adobe Premiere Pro.exe outgoing IP connections altogether. However, it is trying to establish a TCP connection to localhost /

The fix is to allow outgoing TCP (I chose IP, which of course includes TCP) to for the following executables:

  • <Premiere Directory>\Adobe Premiere Pro.exe
  • <Premiere Directory>\32\Adobe QT32 Server.exe
  • <Premiere Directory>\32\dynamiclinkmanager.exe

with <Premiere Directory> of course being the path to your Adobe Premiere directory.

Note: Of course you can still stop every other outgoing traffic. Regard the rule as an exception.

If you are trying to apply this fix to other Adobe programs, you are on your own to find out which .exes require TCP connections. With modern firewalls, however, this shouldn't be that big of a problem. Just look at the prompts your firewall pops up and/or determine the .exes via logging.

I hope that helps you enjoy your respective Adobe program(s) all the more. 🙂

Good luck and, as always, thanks for reading.

Update (2010-03-28):
I recently found out that with my kind of firewall "Adobe Premiere Pro.exe" would prompt me again for a rule for outgoing traffic to addresses different from the localhost zone. If that happens to you, make sure you don't accidentally replace or override the localhost rule you added above. Rather add an additional rule for all the remaining outgoing traffic and forbid it (or allow it, depending on what you want).


OpenVPN on Windows Vista / 7 – Ping says: TTL expired in transit

Hi there!

When I set up my VPN with OpenVPN yesterday, I found out about a little difficulty under Windows Vista and 7. Thankfully it was not that much of a hurdle as the UAC was the reason for this bug just like for a series of other bugs with different software I experimented with over the last few weeks. Nevertheless I hope that this piece of information helps you get rid of the following problem.

If you have set up your VPN and got it running without any major problems, and everything seems to be running just fine (connecting works), but you still can't establish connections to the other machines, you might find that pinging returns the error message "TTL expired in transit". This is due to the fact that Vista (or Windows 7) needs administrator privileges to adjust your computer's settings properly in order to function when you've connected to the VPN successfully. I think it's about the route.exe process, but I'm not 100% sure.

Windows Vista and 7 have the equally famous as infamous UAC (User Account Control) that prevents even administrator privileged accounts from executing programs with administrator rights by default. In order to enable these rights you have to right-click the program (or program shortcut) and click on "Run as administrator" next to the yellow-blue shield if it does not run with administrator rights exclusively anyway (in which case you'd see the yellow-blue shield in the bottom right corner of the program icon itself and would be asked for administrator privileges automatically when you launch it as any other program).

Please note that the following steps are for on-demand OpenVPN connections. For automatic connections, read further below.

OpenVPN on-demand connection

So what you need to do is launch the connection with UAC. But how do you do that if you usually launch OpenVPN connections with a right-click and "Start OpenVPN on this config file"? Even creating a shortcut to the .ovpn file doesn't give you the "Run as administrator" option.

A simple solution is to create a batch file that simply changes to the work directory and executes .ovpn with the openvpn.exe.

Example file "ovpn_connection1.bat":

@echo off
cd \Programs\OpenVPN\config-ondemand\
D:\Programs\OpenVPN\bin\openvpn.exe D:\Programs\OpenVPN\config-ondemand\connection1.ovpn

This batch file has the following parameters/assumptions:

  • Your OpenVPN dir is on the D: partition (otherwise change the drive letter in the respective paths and leave the "D:" line out altogether).
  • The path to your OpenVPN dir is D:\Programs\OpenVPN.
  • Your connection configuration file is located in the config-ondemand subdirectory.

Basically, you just switch to the work directory and execute OpenVPN's openvpn.exe located in its bin dir on the configuration. In a way, this works as a shortcut, but just as an executable batch.

The @echo off part is just so that you won't see the other commands displayed in the window each time you start the connection.

Now you either make a shortcut to this batch file or use it itself.

Whenever you want to start the connection, right-click on it and select "Run as administrator".

Done! Test your ping and it should be fine.

OpenVPN automatic connection

All you need to do is to move the .ovpn configuration file and all the other required files into the config subdirectory of your OpenVPN installation.

When the OpenVPN service (Start => Run => services.msc) is started, it will look for .ovpn files in its config subdirectory and execute them all - with SYSTEM privileges. No UAC circumvention needed.

So just set your OpenVPN service to "Automatic" and you're good to go!

OpenVPN on-demand connection with OpenVPN service

Just do what is described under the "OpenVPN automatic connection" paragraph except for setting the service to "Manual".

Now each time you want to launch the connection, you just need to type "net start OpenVPNService". To stop it, type "net stop OpenVPNService".

Note on using connections with the OpenVPN service

As the OpenVPN service feature executes *all* .ovpn configuration in the config subdirectory, there is no way to manually interfere with one particular connection of that directory and let's say disable it shortly. All config-connections are handled as a group with the OpenVPN service.

So if you need manual independency, look at the on-demand section.

I hope this wasn't all too fuzzy with the wordings and such.

Please comment or contact me if you have any questions on this matter.

Thanks for reading!

%d bloggers like this: