E: Sub-process /usr/bin/dpkg returned an error code (1) is apt's summary, not the cause. The cause is printed a few lines above it, under dpkg: error processing package, and the package to repair is named under Errors were encountered while processing:. Fix that package (here, a corrected version of it) and apt runs clean again.

In the test the package's post-installation script exited with 1. Installing a version whose script succeeds moved the package from iF to ii and dpkg --audit came back empty.

The error

$ cd /tmp && apt-get install -y ./fix10-demo_1.0_all.deb
...
Unpacking fix10-demo (1.0) ...
Setting up fix10-demo (1.0) ...
postinst of fix10-demo 1.0
dpkg: error processing package fix10-demo (--configure):
 installed fix10-demo package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 fix10-demo
E: Sub-process /usr/bin/dpkg returned an error code (1)
exit code: 100

Why it happens

apt hands the actual installing to dpkg. When dpkg reports a failure, apt prints this one generic line and returns 100. Here dpkg unpacked the files, ran the package's postinst script, and the script ended with exit 1, so dpkg left the package unconfigured: 

$ dpkg --audit
The following packages are only half configured, probably due to problems
configuring them the first time.  The configuration should be retried using
dpkg --configure <package> or the configure menu option in dselect:
 fix10-demo           test package for a fixes post

exit code: 0
$ dpkg -l fix10-demo | tail -1
iF  fix10-demo     1.0          all          test package for a fixes post
exit code: 0

The broken package then gets in the way of unrelated installs. Installing jq next downloaded and set up jq, but apt tried to configure fix10-demo again, failed in the same way and ended with the same E: Sub-process /usr/bin/dpkg returned an error code (1) and exit code 100. So when this line shows up on an install of something else, look under Errors were encountered while processing: for the name: it may be a package from an earlier install.

The fix

$ cd /tmp && apt-get install -y ./fix10-demo_1.1_all.deb
...
1 upgraded, 0 newly installed, 0 to remove and 13 not upgraded.
1 not fully installed or removed.
...
Unpacking fix10-demo (1.1) over (1.0) ...
Setting up fix10-demo (1.1) ...
postinst of fix10-demo 1.1
exit code: 0
$ dpkg -l fix10-demo | tail -1
ii  fix10-demo     1.1          all          test package for a fixes post
exit code: 0
$ dpkg --audit
exit code: 0

Version 1.1 had a postinst that exits 0, so dpkg configured it and the status letters changed to ii. With a package from a real feed the equivalent is to fix what its script complained about (read the lines just above dpkg: error processing package) and retry with dpkg --configure, as the audit output suggests; that retry was not part of this test.

How it was reproduced

The capture was made in an ubuntu:24.04 container (Ubuntu 24.04.5 LTS, apt 2.8.3, dpkg 1.22.6) on Docker Engine 29.9.3, standing in for Ubuntu in WSL. As root, two tiny packages named fix10-demo were built with dpkg-deb --build: version 1.0 with a postinst that prints a line and exits 1, and version 1.1 that exits 0. Each was installed with apt-get install -y ./file.deb.

Frequently asked

How do I find which package caused 'Sub-process /usr/bin/dpkg returned an error code (1)'?
Read the lines above it. The package is named after dpkg: error processing package and again under Errors were encountered while processing. dpkg --audit also listed it as half configured.
Why does every apt-get install fail after one package broke?
In the test apt tried to configure the half-configured package again during an unrelated install of jq and ended with the same error and exit code 100.
What does iF mean in dpkg -l?
In the test the package showed iF after its post-installation script failed, and ii after a version with a working script was installed.

More decoded errors in the Fixes category. If apt says dpkg was interrupted instead, see dpkg was interrupted, run dpkg --configure -a.