NetBeans could not start due to wrong JVM version, incompatible library and missing files

NetBeans could not start on a Xubuntu Linux system.

It displayed a splash screen, wrote the message Initializing for a few seconds and then quit.

 

The original distribution was Xubuntu 16.04 LTS which had been updated to Xubuntu 18.04 LTS.

Tried starting NetBeans from terminal and got these warnings:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.netbeans.ProxyURLStreamHandlerFactory (file:/usr/share/netbeans/platform18/lib/boot.jar) to field java.net.URL.handler
WARNING: Please consider reporting this to the maintainers of org.netbeans.ProxyURLStreamHandlerFactory
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

 

Decided to check the startup activity with:

strace netbeans 2> netbeans_strace.txt

Noticed that NetBeans was looking for configuration files in 3 locations:

stat("/usr/share/netbeans/8.1/etc/netbeans.conf", {st_mode=S_IFREG|0644, st_size=2958, ...}) = 0
stat("/etc/netbeans.conf", {st_mode=S_IFREG|0644, st_size=2958, ...}) = 0
stat("~/.netbeans/8.1/etc/netbeans.conf", 0x7ffc7aae8df0) = -1 ENOENT (No such file or directory)

 

Decided to look for other files under: ~/.netbeans/8.1/

Found log files under: ~/.netbeans/8.1/var/log/

Part of: ~/.netbeans/8.1/var/log/messages.log

Product Version = NetBeans IDE 8.1 (Build 20180221-debian-8.1)
Java Home = /usr/lib/jvm/java-11-openjdk-amd64
...
-------------------------------------------------------------------------------
java.lang.SecurityException: setContextClassLoader
at java.base/jdk.internal.misc.InnocuousThread.setContextClassLoader(InnocuousThread.java:116)
...

 

Discovered that NetBeans 8.1 requires JDK 8.

Found JDK 8 under:

/usr/lib/jvm/java-8-openjdk-amd64/

Created the folder:

~/.netbeans/8.1/etc/

Then created the configuration file:

~/.netbeans/8.1/etc/netbeans.conf

With a single line:

netbeans_jdkhome="/usr/lib/jvm/java-8-openjdk-amd64"

 

This seemed to help somewhat, because the splash screen continued until:

Turning on modules…

But then it quit again…

 

Found and examined: ~/.netbeans/8.1/var/log/messages.log

Noticed this part:

Product Version = NetBeans IDE 8.1 (Build 20180221-debian-8.1)
Java Home = /usr/lib/jvm/java-8-openjdk-amd64/jre
...
-------------------------------------------------------------------------------
INFO [org.netbeans.modules.netbinox]: Install area set to file:/usr/share/netbeans/8.1/
java.lang.NullPointerException
at org.eclipse.osgi.baseadaptor.BaseAdaptor.initializeStorage(BaseAdaptor.java:123)
at org.eclipse.osgi.framework.internal.core.Framework.<init>(Framework.java:192)
at org.eclipse.osgi.framework.internal.core.EquinoxLauncher.internalInit(EquinoxLauncher.java:67)
at org.eclipse.osgi.framework.internal.core.EquinoxLauncher.init(EquinoxLauncher.java:37)
at org.eclipse.osgi.launch.Equinox.init(Equinox.java:178)
at org.netbeans.modules.netbinox.Netbinox.init(Unknown Source)
at org.netbeans.core.netigso.Netigso.prepare(Unknown Source)
at org.netbeans.NetigsoHandle.turnOn(Unknown Source)
at org.netbeans.ModuleManager.enable(Unknown Source)
INFO [null]: Last record repeated again.
at org.netbeans.core.startup.ModuleList.installNew(Unknown Source)
at org.netbeans.core.startup.ModuleList.trigger(Unknown Source)
at org.netbeans.core.startup.ModuleSystem.restore(Unknown Source)
at org.netbeans.core.startup.Main.getModuleSystem(Unknown Source)
INFO [null]: Last record repeated again.
at org.netbeans.core.startup.Main.start(Unknown Source)
at org.netbeans.core.startup.TopThreadGroup.run(Unknown Source)
at java.lang.Thread.run(Thread.java:748)

 

Found this site, which seemed to describe this part of the problem:

https://bugs.launchpad.net/ubuntu/+source/netbeans/+bug/1776937

 

Checked the installed version of libequinox-osgi-java which was: 3.9.1-1

Downloaded: libequinox-osgi-java_3.8.1-10_all.deb

From: https://packages.ubuntu.com/artful/all/libequinox-osgi-java/download

 

Installed the package with:

sudo dpkg -i libequinox-osgi-java_3.8.1-10_all.deb

Held the package at the old version with:

sudo apt-mark hold libequinox-osgi-java

 

Tried starting NetBeans again, but it still failed to start.

Found errors in: ~/.netbeans/8.1/var/log/messages.log

Like:

!ENTRY org.eclipse.osgi 4 0 2018-10-15 22:49:29.510
!MESSAGE Error reading configuration: Unable to create lock manager.
!STACK 0
java.io.IOException: Unable to create lock manager.
at org.eclipse.osgi.storagemanager.StorageManager.open(StorageManager.java:699)

 

Tried running NetBeans as root with:

sudo netbeans

It started up without crashing…

 

It was still unable to start under the regular user account.

Noticed that it had created some files with root as owner:

!ENTRY org.eclipse.osgi 4 0 2018-10-15 23:05:36.425
!MESSAGE Error reading configuration: Permission denied
!STACK 0
java.io.IOException: Permission denied
at java.io.UnixFileSystem.createFileExclusively(Native Method)
at java.io.File.createTempFile(File.java:2024)
at org.eclipse.osgi.storagemanager.StorageManager.initializeInstanceFile(StorageManager.java:188)

 

Decided to change the file permissions with:

sudo chown $USER:$USER ~/.netbeans/ -R

sudo chown $USER:$USER ~/.cache/netbeans/ -R

 

This was the last step. After this NetBeans could finally start normally again.

Conclusion

If NetBeans fails to start on Ubuntu/Xubuntu 18.4 LTS try these things:

  • Check and change used JDK to version 8.
  • Downgrade libequinox-osgi-java package from 3.9.1-1 to 3.8.1-10 and hold/pin it.
  • Run NetBeans as root once.
  • Change NetBeans file permissions to normal user permissions.

Android emulator crashing due to access violation

I recently experienced a situation where Android Studio’s emulator crashed when starting an app that performed basic graphics operations.

Crash reason: EXCEPTION_ACCESS_VIOLATION_WRITE
Crash address: 0x66720000
Assertion: Unknown assertion type 0x00000000
Process uptime: 13 seconds

 

I started up Process Monitor to investigate the issue.

Tried recreating the situation, then stopped capturing events with: File -> Capture Events

Wanted to get an overview of the processes involved with: Tools -> Process Tree…

Right clicked studio64.exe and selected: Add process and children to Include filter

 

Noticed that emulator64-crash-service.exe left a memory dump under:

C:\Users\{user}\.android\breakpad\d16b5760-c4ac-4f06-a3ec-73aa74a70087.dmp

 

Examined the memory dump with WinDbg (x64).

Checked for details about the crash with:

!analyze -v

Part of the result:

FAULTING_IP:
ig9icd64!RegisterProcTableCallback+196cfb
000007fe`c5d9f71b f3410f7f48c0 movdqu xmmword ptr [r8-40h],xmm1

EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 000007fec5d9f71b (ig9icd64!RegisterProcTableCallback+0x0000000000196cfb)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000001
Parameter[1]: 000000000ba50000
Attempt to write to address 000000000ba50000

STACK_TEXT:
... : ig9icd64!RegisterProcTableCallback+0x196cfb
... : ig9icd64!RegisterProcTableCallback+0x4a228e
... : ig9icd64!RegisterProcTableCallback+0x4a36b4
... : ig9icd64!RegisterProcTableCallback+0x4a828d
... : ig9icd64!RegisterProcTableCallback+0x4c52c7
... : ig9icd64!RegisterProcTableCallback+0x4c500f
... : ig9icd64!RegisterProcTableCallback+0x2ee1a2
... : lib64GLES_V2_translator!glReadPixels+0x297
... : lib64OpenglRender+0x364d
... : lib64OpenglRender+0x773b
... : lib64OpenglRender+0x11009
... : lib64OpenglRender!initLibrary+0x52e3
... : lib64OpenglRender!initLibrary+0xc4e2c
... : lib64OpenglRender!initLibrary+0x4c7a4
... : kernel32!BaseThreadInitThunk+0xd
... : ntdll!RtlUserThreadStart+0x1d

 

This indicated that the problem was related to graphics drivers and/or settings.

I did not have important data on the Android emulator, so I made it boot again by removing all data (including the auto-starting app, which crashed the emulator).

Did this in Android Virtual Device manager with the Wipe Data option.

 

When the emulator could start again I started looking for additional graphics settings.

Found some under Extended controls -> Settings section -> Advanced tab.

The default setting for OpenGL ES renderer (Autodetect based on host) seemed problematic on this system.

I experimented with the settings and discovered that SwiftShader worked well. Running graphics rendering apps with this setting no longer crashed the emulator.

The problem occurred on a desktop system with an Intel Skylake CPU (Core i7-6700) running Windows 7 using Intel HD Graphics 530 with driver version 21.20.16.4860.

Conclusion

If Android Studio’s emulator crashes when running graphics rendering apps, it may help changing the OpenGL ES renderer setting.

Calculating checksums with CertUtil

There are many utilities which can calculate file checksums.

However, in some cases it’s not an option to use a third-party tool. For instance:

  • The system is permanently or temporarily disconnected from a network.
  • Allowed software is restricted due to policies.

 

But Windows has a built-in tool, which can calculate file checksums: CertUtil

The syntax is:

certutil -hashfile file_to_check.bin [HashAlgorithm]

 

Among the supported hash algorithms are MD5, SHA1 and SHA256.

Be aware that the hash algorithm has to be in uppercase or the command can fail with:

CertUtil: -hashfile command FAILED: 0xd00000bb (-805306181)
CertUtil: WsResetMetadata

 

Example of use:

certutil -hashfile c:\Windows\System32\calc.exe MD5

Result:

MD5 hash of file c:\Windows\System32\calc.exe:
10 e4 a1 d2 13 2c cb 5c 67 59 f0 38 cd b6 f3 c9
CertUtil: -hashfile command completed successfully.

VirtualBox VM failing to start with virtual serial port

I recently needed to emulate an RS232 serial port in a Linux guest VM running in VirtualBox on Windows 7.

Specifically I needed to map the virtual serial port to a TCP network port.

 

This didn’t work as expected. When the serial port was enabled the virtual machine crashed immediately on startup with this message:

The instruction at 0xcdcfdcab referenced memory at 0x00000018.
The memory could not be read.

Click on OK to terminate the program
Click on CANCEL to debug the program

 

Followed by another message:

Failed to open a session for the virtual machine PM Devel.

The VM session was aborted.

Result Code: E_FAIL (0x80004005)
Component:   SessionMachine
Interface:   ISession {7844aa05-b02e-4cdd-a04f-ade4a762e6b7}

 

I checked for problem causes using Event Viewer, VBox.log, Process Monitor, Procdump and WinDbg. Unfortunately none of these revealed the cause.

 

I rechecked the settings and noticed: Connect to existing pipe/socket

This was checked by default. Tried unchecking the setting.

 

This solved the problem.

The virtual machine could start normally and communication between the virtual RS232 serial port and the TCP network port worked.

Be aware that a VirtualBox VM may also crash on shutdown in a similar way, if the TCP port is still connected.

Adjust Power Options to prevent DRIVER_POWER_STATE_FAILURE (9f) BSOD

I recently updated the NIC driver on my work computer in an attempt to fix a BSOD problem.

Unfortunately it did not help. The computer would still regularly hang and eventually crash when shutting down to sleep mode with:

The computer has rebooted from a bugcheck. The bugcheck was: 0x0000009f (0x0000000000000003, 0xfffffa800d1eba10, 0xfffff80004d3a3d8, 0xfffffa802eba1c60).
DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time.

 

Decided to investigate the settings under: Control Panel -> Power Options

 

Noticed multiple settings called Link State Power Management and decided to disable them.

PCI Express -> Link State Power Management: Off

Low Power Active Mode profile -> Link State Power Management: No Power Saving

Idle mode optimization profile -> Link State Power Management: No Power Saving

(Expecting that the first setting under PCI Express was the important one, but disabled the others just in case)

 

It seems that none of the standard power plans disable these settings, not even High performance.

If you switch between multiple power plans, you will have to modify them all.

 

After modifying the power options I have shut down the computer to sleep mode successfully 15 times without a single hang.

Disabling PCIe Link State Power Management seems to have fixed the DRIVER_POWER_STATE_FAILURE (9f) BSOD problems.

Examining DRIVER_POWER_STATE_FAILURE (9f) BSOD

My work computer recently hanged when shutting down to sleep mode.

When booting the computer the next day I realized that it had eventually crashed.

This happened again after disabling hyper-threading, so I decided to investigate.

 

Checked Event Viewer and found:

Log Name: System
Source: Microsoft-Windows-WER-SystemErrorReporting
Event ID: 1001
Task Category: None
Level: Error
Keywords: Classic
Description:
The computer has rebooted from a bugcheck. The bugcheck was: 0x0000009f (0x0000000000000003, 0xfffffa800cd5e060, 0xfffff80000b9a3d8, 0xfffffa802e232590). A dump was saved in: C:\Windows\MEMORY.DMP.

 

Searched online for BSOD 0x0000009f and found:

https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x9f–driver-power-state-failure

 

Examined the memory dump with WinDbg (x64).

Checked for details about the crash with:

!analyze -v

Part of the result:

DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time.
Arguments:
Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
Arg2: fffffa800cd5e060, Physical Device Object of the stack
Arg3: fffff80000b9a3d8, nt!TRIAGE_9F_POWER on Win7 and higher, otherwise the Functional Device Object of the stack
Arg4: fffffa802e232590, The blocked IRP

FAILURE_BUCKET_ID: X64_0x9F_3_POWER_DOWN_Rt64win7_IMAGE_pci.sys

BUCKET_ID: X64_0x9F_3_POWER_DOWN_Rt64win7_IMAGE_pci.sys

FAILURE_ID_HASH_STRING: km:x64_0x9f_3_power_down_rt64win7_image_pci.sys

 

Checked for information about the I/O request packet with:

!irp fffffa802e232590

Result:

Irp is active with 5 stacks 4 is current (= 0xfffffa802e232738)
No Mdl: No System Buffer: Thread 00000000: Irp stack trace.
cmd flg cl Device File Completion-Context
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
>[ 16, 2] 0 e1 fffffa800da84050 00000000 fffff800032ca230-fffffa800eb3bb50 Success Error Cancel pending
*** ERROR: Module load completed but symbols could not be loaded for Rt64win7.sys
\Driver\RTL8167 nt!PopSystemIrpCompletion
Args: 00015400 00000000 00000005 00000003
[ 0, 0] 0 0 00000000 00000000 00000000-fffffa800eb3bb50

Args: 00000000 00000000 00000000 00000000

 

Examined available information about Rt64win7 with:

lmvm Rt64win7

Result:

start end module name
fffff880`05c3a000 fffff880`05d39000 Rt64win7 (no symbols)
Loaded symbol image file: Rt64win7.sys
Image path: \SystemRoot\system32\DRIVERS\Rt64win7.sys
Image name: Rt64win7.sys
Timestamp: Fri Oct 07 11:27:12 2016 (57F76A70)
CheckSum: 0010CDA5
ImageSize: 000FF000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4

 

Found the driver file in Windows explorer under:

C:\Windows\system32\DRIVERS\Rt64win7.sys

Then checked Properties. The details view confirmed that the driver was for the Realtek network interface card, version: 7.103.1007.2016.

 

Decided to look for a newer driver from Realtek.

Found, downloaded and installed the current latest version 7.109.

Unfortunately this was not the solution, the problems continued.

However, later on I discovered that adjusting power options seemed effective.

Android emulator hanging with black screen

I recently experienced a situation where Android Studio’s x86 emulator would not start.

It just showed a black screen with no apparent progress.

 

To investigate I connected Android Device Monitor to the emulator.

LogCat showed a lot of messages and they seemed to repeat over and over.

 

I decided to pause the emulator to examine the log.

Found and followed Christoper Orr’s advice here:

telnet localhost 5554
avd stop

 

Checked the LogCat messages and noticed this section:

I/ServiceManager(16997): Waiting for service SurfaceFlinger...
I/SurfaceFlinger(17248): SurfaceFlinger is starting
I/SurfaceFlinger(17248): SurfaceFlinger's main thread ready to run. Initializing graphics H/W...
D/libEGL(17248): Emulator has vendor provided software renderer, qemu.gles is set to 2.
D/libEGL(17248): loaded /vendor/lib/egl/libEGL_swiftshader.so
D/libEGL(17248): loaded /vendor/lib/egl/libGLESv1_CM_swiftshader.so
D/libEGL(17248): loaded /vendor/lib/egl/libGLESv2_swiftshader.so
D/gralloc_ranchu(17248): Emulator without host-side GPU emulation detected.
E/gralloc_ranchu(17248): Could not find software fallback module!?
E/gralloc_ranchu(17248): [ 07-04 12:54:38.858 17248:17248 E/ ]
E/gralloc_ranchu(17248): connect: failed with fd -1 errno 22
E/gralloc_ranchu(17248): [ 07-04 12:54:38.858 17248:17248 E/ ]
E/gralloc_ranchu(17248): Failed to connect to host (QemuPipeStream)!!!
E/gralloc_ranchu(17248): gralloc: Failed to get host connection
E/SurfaceFlinger(17248): hwcomposer module not found
E/SurfaceFlinger(17248): ERROR: failed to open framebuffer (I/O error), aborting
A/libc(17248): Fatal signal 6 (SIGABRT), code -6 in tid 17248 (surfaceflinger)
A/libc(17248): [ 07-04 12:54:38.858 1319: 1319 W/ ]
A/libc(17248): debuggerd: handling request: pid=17248 uid=1000 gid=1003 tid=17248
I/ServiceManager(17212): Waiting for service SurfaceFlinger...
I/ServiceManager(17212): [ 07-04 12:54:38.860 17256:17256 E/ ]
I/ServiceManager(17212): debuggerd: Unable to connect to activity manager (connect failed: Connection refused)

 

Decided to check the emulator configuration.

Noticed that the emulator was configured to use software graphics.

Changed this to hardware graphics, started the emulator again and noticed that it started normally. The workaround solved the problem.

 

Conclusion

If the Android Studio emulator hangs with a black screen, try checking the LogCat messages and try switching graphics mode.

Disable hyper-threading on Intel Skylake & Kaby Lake CPU

In 4½ months I have experienced 16 BSOD system crashes on a new work computer:

Crash Date Bug Check String Bug Check Code Caused By Address
21-06-2017 DRIVER_POWER_STATE_FAILURE 0x0000009f ntoskrnl.exe+70e40
12-06-2017 NTFS_FILE_SYSTEM 0x00000024 Ntfs.sys+4211
23-05-2017 IRQL_NOT_LESS_OR_EQUAL 0x0000000a ntoskrnl.exe+6f4c0
10-05-2017 IRQL_NOT_LESS_OR_EQUAL 0x0000000a ntoskrnl.exe+6f440
01-05-2017 BAD_POOL_HEADER 0x00000019 win32k.sys+f13b2
24-03-2017 BAD_POOL_CALLER 0x000000c2 ntoskrnl.exe+6f440
17-03-2017 SYSTEM_SERVICE_EXCEPTION 0x0000003b afd.sys+41448
14-03-2017 MEMORY_MANAGEMENT 0x0000001a ntoskrnl.exe+70400
13-03-2017 PAGE_FAULT_IN_NONPAGED_AREA 0x00000050 VBoxDrv.sys+1f037
10-03-2017 PFN_LIST_CORRUPT 0x0000004e ntoskrnl.exe+70400
02-03-2017 SYSTEM_SERVICE_EXCEPTION 0x0000003b ntoskrnl.exe+70400
22-02-2017 BAD_POOL_CALLER 0x000000c2 TDI.SYS+10be
17-02-2017 BAD_POOL_HEADER 0x00000019 ntoskrnl.exe+70400
16-02-2017 SYSTEM_THREAD_EXCEPTION_NOT_HANDLED 0x1000007e iusb3xhc.sys+7dfb0
08-02-2017 PAGE_FAULT_IN_NONPAGED_AREA 0x00000050 ntoskrnl.exe+70400
07-02-2017 PFN_LIST_CORRUPT 0x0000004e ntoskrnl.exe+70400

 

Until now I have:

  • Performed multiple memory tests.
  • Checked SSD health.
  • Checked system files.
  • Examined multiple memory dumps with WinDbg.
  • Installed all relevant firmware and driver updates.
  • Scanned for malware.

 

However this has not been successful or revealed the real cause behind the problems.

 

I eventually decided to replace the original memory modules:

2 x 8 GB DDR4-2133 CL15, Kingston KVR21N15D8K2/16

With:

2 x 8 GB DDR4-2133 CL15, Crucial CT8G4DFS8213.C8FDR1

 

This seemed to help somewhat.

System crashes used to be a semiweekly event.

After replacing the memory modules it became a semimonthly event.

 

The system has an Intel Skylake CPU (Core i7-6700)

 

It has recently been discovered that some Intel Skylake and Kaby Lake CPU’s have a hardware bug related to hyper-threading.

The bug is described in: 6th Generation Intel® Processor Family – Specification Update

Quote:

“Under complex micro-architectural conditions, short loops of less than 64 instructions that use AH, BH, CH or DH registers as well as their corresponding wider register (e.g. RAX, EAX or AX for AH) may cause unpredictable system behavior. This can only happen when both logical processors on the same physical processor are active.”

 

Until system vendors include microcode fixes in firmware/UEFI updates, the only workaround is to disable hyper-threading.

 

The stability problems I have experienced could be caused by this CPU hardware bug.

So I have disabled hyper-threading in BIOS/UEFI setup and will await firmware updates. I hope that the system will finally be stable and reliable.

Conclusion

If you have an Intel Skylake or Kaby Lake CPU, it is recommend to disable hyper-threading for now.

Removing blank pages from PDF files

wkhtmltopdf converts HTML content into PDF format, which can be a simple and effective way to generate PDF files.

However sometimes wkhtmltopdf generates a blank last page, depending on the original content.

 

It may not be obvious which changes are needed in the original content to avoid this problem.

A viable workaround could be processing PDF files to remove blank pages.

I decided to investigate how to do this.

 

PDF files contains objects, including media, page content, page definitions and a page index.

Here’s an example of the page index:

3 0 obj
<<
/Type /Pages
/Kids
[
6 0 R
14 0 R
19 0 R
24 0 R
]
/Count 4
/ProcSet [/PDF /Text /ImageB /ImageC]
>>
endobj

 

The page index can be recognized by the identifier: /Type /Pages

Objects are numbered. In this case the page index itself had the number 3 0, while the last page had the number 24 0

 

Searched for the last page (24 0 obj) and found:

24 0 obj
<<
/Type /Page
/Parent 3 0 R
/Contents 25 0 R
/Resources 27 0 R
/Annots 28 0 R
/MediaBox [0 0 612 792]
>>
endobj

 

The page definition contained a reference to the actual content.

Searched for the content (25 0 obj) and found:

25 0 obj
<<
/Length 26 0 R
/Filter /FlateDecode
>>
stream
... (encoded content left out) ...
endstream
endobj

 

Searched for the content length (26 0 obj) and found:

26 0 obj
203
endobj

 

A small content length was a good indication that the last page was blank. 203 bytes was not a lot of content, so I decided to remove the last page from the page index.

(A nicer but much more complicated solution would be to decode the content, analyze it and determine if the page was blank or not)

 

Modified the page index by removing the original last page and decrementing the count like this:

3 0 obj
<<
/Type /Pages
/Kids
[
6 0 R
14 0 R
19 0 R
]
/Count 3
/ProcSet [/PDF /Text /ImageB /ImageC]
>>
endobj

 

This was enough to remove the blank page from the PDF file.

Determined that the modified PDF looked like expected with:

  • Adobe Acrobat Reader DC
  • Sumatra PDF
  • Evince Document Viewer
  • Firefox
  • Chrome

(If the PDF had contained a visible total page count, additional modifications may have be needed after removing the blank page)

Conclusion

A program could use this technique to remove a blank last page in a PDF file:

  1. Search page index (/Type /Pages) for the last page.
  2. Find the last page.
  3. Find the content.
  4. Find the content length.
  5. If the content length is small, then remove the last page from the page index and decrement the total page count.

Error when copying large files to USB memory stick

While copying files to a new USB memory stick I encountered unexpected error messages in Windows.

 

Robocopy failed with:

2017/05/04 21:45:38 ERROR 87 (0x00000057) Copying File f:\Transport\Test\4GB.txt

The parameter is incorrect.

 

Cmd copy failed with:

The parameter is incorrect.

 

PowerShell Copy-Item failed with:

Copy-Item : The parameter is incorrect.
At line:1 char:10
+ Copy-Item <<<<  .\4GB.txt G:\
+ CategoryInfo          : NotSpecified: (:) [Copy-Item], IOException
+ FullyQualifiedErrorId : System.IO.IOException,Microsoft.PowerShell.Commands.CopyItemCommand

 

Windows explorer copy & paste failed with:

The file '4GB.txt' is too large for the destination file system.

 

This prompted me to check the file system, which was FAT32.

FAT32 has a file size limitation of 4 GB, a problem I have encountered before.

Like before I decided to reformat the USB memory stick to NTFS, which solved the problem.