Installation doesn't work, tools missing or don't work, MiKTeX Console doesn't work

[ChrisChiesa]

Using Windows 10. I have a PDF page-layout problem that (a particular AI that shall remain nameless) says can be addressed using MiKTeX and a short .tex script that it has composed. Considering that I've been curious about TeX for the 40+ years I've been a software engineer, I was excited to have an excuse / opportunity to check it out. Unfortunately, the first hour-and-a-half have been a nightmare that leaves me no closer to getting any LaTeX output than I was forty years ago.

First hurdle: "Windows 11" as the only supported version of Windows. AI assures me this is just a technicality and can be handwaved away, so I download and install. The bare bones statement that "the MiKTeX Installer ran As Administrator without popping up any errors," while technically true, is deeply misleading; considering how things turned out, it should have popped up several errors, warnings, complaints, etc.

First, it wanted to put the installation into C:\Users\myname\AppData -- the last place on Earth I would ever LOOK for an installed software package, after thirty years of C:\Program Files -- so I manually overrode that path with C:\Program Files\MiKTeX. Didn't work, the first time -- I forget what the error was -- but the second time I took pains to MANUALLY CREATE the destination folder FIRST (I would have expected the Installer itself to do that, just saying; please fix this), and it "succeeded" as noted previously.

Next, there WAS NO "pdflatex" anywhere in the tree rooted at the installation directory, after the supposedly-"successful" installation. How about a warning or error, if you can't do all the steps? Duh. Turned out I had to open an Administrator console and run

"C:\Program Files\MiKTeX\miktex\bin\x64\initexmf.exe" --admin --mklinks

which brought pdflatex.exe into being. Why it worked when launched manually, but couldn't happen when running the Installer "As Administrator" in the first place, I'll never know. Please fix this.

Next, when I managed to launch "pdflatex" to run the AI's little script, the first thing that happened was that I got a whole slew of errors cryptic to me, but which the AI instantly recognized as my SOURCE PDF FILE'S NAME HAVING UNDERSCORES IN IT. -- Really? In 2026? Forty years of development, and your program STILL can neither handle underscores in a filename (on Windows where that's perfectly legal), or NOTICE THAT, UP FRONT, STOP THERE, and TELL ME THAT'S THE PROBLEM? It IGNORES the problem with the filename until much later when it causes otherwise-perfectly-okay file content to be reported AS THOUGH there were a problem. It DOESN'T EVEN MAKE LOGICAL SENSE for problems in a FILE NAME to get conflated with syntax issues in that file's CONTENT. Please fix this.

If I weren't working with the AI I would never have figured out what was wrong. Come on, you guys; do better!

I renamed my source input file and tried again, and got only ONE error: "Package geometry.sty not installed". The AI told me to issue a command

mpm --admin --install=geometry

which first reported that "--install" is deprecated... then "Sorry, but: The executed process did not succeed."

That's NOT HELPFUL. What now?!?

The AI next recommended that I fire up the MiKTeX Console, and gave me a command to do that. That command popped up an error that "the MiKTeX Console is already running," despite its not having a window open anywhere. The AI clued me in that it was hiding in the Tray area of the Taskbar. I managed to open it from there, and was immediately asked whether I wanted to "Switch to Administrator Mode" (sic) or "Stay in User Mode." I guessed, correctly according to the AI, that since "everything else has required me to be in Administrator Mode, I guess I want to switch to Administrator Mode." When I clicked the link to do that, I got... a warning or error dialog asking me to make sure that I really wanted to EXIT the MiKTeX Console -- which, no, I didn't, I merely wanted to SWITCH MODES. I figured out that "switching modes" must be a process of ending ONE incarnation of the console, and starting a fresh new one, and so clicked okay, but -- that wording is unexpected in that context and you need to have the software notice FROM WHERE it is being triggered and use a different wording when it's "Switch Mode..." That, or put some hint text up, before that, INFORMING the user that "Switching modes means exiting and restarting the Console, so don't panic at the next error message you see." Please fix this.

The restart of the MiKTeX Console then complained that "no Administrator has yet checked for updates" -- well, NO, THEY HAVEN'T, BECAUSE THEY HAVEN'T GOTTEN ANYWHERE NEAR FAR ENOUGH TO TRY. How about toning down the nannying? Please fix this.

So the AI said I should "click the big 'Check for Updates' button," which of course didn't exist -- but you know how AIs are, so I didn't worry too much about that. I clicked the "Updates" item in the sidebar instead, and got an Updates panel unto itself that DID contain a "Check for Updates" button.

Clicking THAT "Check for Updates" button produced the not-at-all useful error message, "Sorry, something went wrong. Do you want to see the details?" Clicking YES to see the details (yeah, I'm masochistic like that) popped up a "MiKTeX Error Report - MiKTeX Console" window with two large textboxes, empty except in the upper one the words, "internal error." THIS IS NOT HELPFUL. Please fix this. Clicking "Update now" on the off chance that something might be preconfigured, pops up the exact same "Sorry..." etc. error and "internal error" "details" panel. Please fix this.

Fortunately there is ALSO a "Packages" item in the sidebar, so I clicked THAT and navigated down to "geometry", clicked on it, right-clicked, and chose "Install package." Remarkably, that seemed to work, and in the "Installed by" column which is blank for the other 100 packages listed, now in the line for "geometry" appears the name, "Admin".

The AI says I should also install package "pdfpages" -- and I'd swear I saw that, too, on the list where I clicked on "geometry" and successfully installed it -- but it's no longer there, so I have no idea, now, how to go about installing THAT.

All in all this is the most labyrinthine, confusing, often-misleading, bad-surprise-laden, travesty of a software installation process I have seen in over forty years of software engineering. I could have done better in 1987 on a VAX/VMS machine with no GUI, just a dictionary of commands to memorize and type.

By that time I was so infuriated that it would have taken a godlike effort of will to keep this very post from being a cesspool of obscenities and objectives, but after the fifteen-minute slog to figure out how to even START composing this, I managed to calm down a little. This is me being CALM.

So -- how do I install the next thing "pdflatex" is going to complain about? Why can't I check for updates? Why can't I update? -- and who the heck ever approved this nightmare (a polite term for it, believe me) for release? This is IN NO WAY "ready for prime time," even by the standards in place in 1988, let alone 2026, unless progress has been rapidly going BACKWARDS since I retired in 2016. Sorry for the "tone," but -- see the previous paragraph and thank your lucky stars.

Oh, and I absolutely HAVE NOT "done a search for similar discussions" because (a) this page is as obscurely non-intuitive as MiKTeX itself and I have NO IDEA HOW to search for a similar discussion, and (b) if anybody had ever had any of these problems just getting the darned thing installed and running, I assume you would have already fixed all this stuff.

[CoderDeltaLAN]

Sorry you hit such a rough path here. The main thing I’d try is to stop mixing install modes. Since you installed into C:\Program Files\MiKTeX, treat it as a shared/admin install and run the repair/install steps from an elevated PowerShell:

cd "C:\Program Files\MiKTeX\miktex\bin\x64"
.\miktex.exe --admin links install --force
.\miktex.exe --admin packages update-package-database
.\miktex.exe --admin --enable-installer packages install geometry pdfpages
.\miktex.exe --admin packages update
.\miktex.exe --admin fndb refresh

Then try compiling again from that same terminal:

.\pdflatex.exe "your-file.tex"

For now I’d also rename the input PDF to something boring like input.pdf, just to remove filename parsing as another variable while the installation is being fixed.

If it still fails, the useful thing to post would be the real command output, not the Console popup:

cd "C:\Program Files\MiKTeX\miktex\bin\x64"
.\miktex.exe --admin --verbose packages install pdfpages
.\initexmf.exe --admin --report

Also, if you are not committed to a shared install, honestly the less painful MiKTeX path is probably to uninstall and reinstall with the default per-user/private install. That avoids a lot of the admin/user split that seems to be biting you here.

[ChrisChiesa]

Thanks for the quick response! My "commonsense notions" of how to use computers clearly differ from those of the people writing software the last forty years;. not for me administrative consoles, OS nannying (the biggest culprit in all of this!), and layer-upon-layer of abstraction and fanciness; I'm not even a big fan of GUIs, and if you ever find a Usenet archive from circa 1986-95 you'll find me ranting away in fiery opposition to the whole damned technology. I was happier sending individual ASCII character codes to an Epson dot-matrix printer in 1985 than I've been with just about any printing "advance" or "improvement" foisted upon us since. But I digress. After posting this evening's rant, I went back and tried *pdflatex *again -- and miraculously, it worked! I've spent the last couple of hours since, fighting the poor quality of the *results *being generated in multiple languages and formats about which I know little or nothing: PDF, PostScript, LaTeX, ... and trying to balance some disappointing tradeoffs between domain-and-application demands and printer rendering engine limitations (600 dpi just isn't enough;now (and not for the first time) I miss the olden days of good ol' optically-produced *microfiche**; *you could get an entire issue of Newsweek on a piece of film about 5x7 inches. Talk about *resolution! *SIGH** I had no idea I *was *"mixing install modes" -- I don't even know, and tend to disagree, that I even *did so. *In any case, though, that's something else that ought to be called out by the Installer if it finds itself being commanded to do something it doesn't want to, don't you think? All *I *did was run the Installer "as Administrator," so that it didn't complain about inability to write files in C:\Program Files. That ought to Just Work, don't you think? I certainly do! None of which actually addresses the MiKTeX Console's steadfast refusal to update or to tell me the nature of the problem. That's NOT USEFUL, gentlemen. From other remarks of yours just now, I infer that *to you, *putting executables, software packages, etc. into C:\Program FIles is a "shared install," whereas a "private/per-user install" goes into C:\User\*myname*\AppData [...] When did *that *start? I've never seen, heard of, or otherwise experienced, that before tonight, I may have found code "lurking" in AppData, but I considered that either an error or a sign of malware trying to sneak in unnoticed; there's certainly been absolutely zero precedent for that being a legitimate *or reasonable *place to put installed software! If I were going to do a thing like *that, *I'd simply create an *Installed *folder on my Desktop and put everything in *there.* That way at least it would be in my face enough, now and then, that I'd *know it was there *and *remember it existed.* I have been aware of C:\Program Files for 25 years, of C:\Program Files (x86) for 15 years or so (whenever 64-bit Windows first came out), and have never had *any idea whatsoever *that *executable code *would ever, under any circumstances or for any reason, go anywhere else, least of all into AppData -- the name of which, you'll note, specifically says that it's for *data, **not code.* So if that directory has been a standard place to put executable code for some length of time now, I'd like to know just when that started and why nobody told me! ;-) Anyway -- I am in no way dedicated to a shared installation. I merely wish Windows to continue working as it always has: putting installed software into C:\Program Files (with or without the (x86) suffix) by default, and Just Working. I have a standing vow never to have anything to do with Windows 11 because of the excessive nannying and number of changes from long-established standards of behavior, and it's starting to look like I should have sworn off Windows 10, too, when I briefly had the chance -- or maybe Windows 7. I will tell you with a straight face that XP was the pinnacle of Windows usability, stability, and capability-without-obstacles, and that every version of Windows since then has been a step in the wrong direction. If you guys ever want to gin up a grassroots organization to buy the rights and source code to XP, and put it out again *ENTIRELY UNCHANGED (resisting the temptation to tinker, "improve" it, or "fix" anything!), *let me know, 'cause *I'm in!* But again I digress. It did occur to me to simply uninstall MiKTeX -- but the whole AppData thing just really puts me off. The AI mentioned some other TeX implementation / package I could try if I didn't like MiKTeX, so maybe that's the way to go. It seems like too much work, right now, but I'm up against a hard deadline on something that has to be done before the gasoline / diesel / electricity fail for good, which could happen at pretty much any time now. Ah well. Thanks again for responding. Chris Chiesa

…

On Sat, Jul 11, 2026 at 8:27 PM Yosvel ***@***.***> wrote: Sorry you hit such a rough path here. The main thing I’d try is to stop mixing install modes. Since you installed into C:\Program Files\MiKTeX, treat it as a shared/admin install and run the repair/install steps from an elevated PowerShell: cd "C:\Program Files\MiKTeX\miktex\bin\x64" .\miktex.exe --admin links install --force .\miktex.exe --admin packages update-package-database .\miktex.exe --admin --enable-installer packages install geometry pdfpages .\miktex.exe --admin packages update .\miktex.exe --admin fndb refresh Then try compiling again from that same terminal: .\pdflatex.exe "your-file.tex" For now I’d also rename the input PDF to something boring like input.pdf, just to remove filename parsing as another variable while the install is being fixed. If it still fails, the useful thing to post would be the real command output, not the Console popup: cd "C:\Program Files\MiKTeX\miktex\bin\x64" .\miktex.exe --admin --verbose packages install pdfpages .\initexmf.exe --admin --report Also, if you are not committed to a shared install, honestly the less painful MiKTeX path is probably to uninstall and reinstall with the default per-user/private install. That avoids a lot of the admin/user split that seems to be biting you here — Reply to this email directly, view it on GitHub <#1749?email_source=notifications&email_token=AYZHN4BISHZ46J7RCVIXVHD5ELLONA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZWGA4TAOBQUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-17609080>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AYZHN4BBQJSO5PMYCE5W5LT5ELLONAVCNFSNUABHKJSXA33TNF2G64TZHM3DCOBZGIYTQOJ3IRUXGY3VONZWS33OHMYTANBRGI3TGMFBOYBA> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AYZHN4HMT457MGNGF7RZLAD5ELLONA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZWGA4TAOBQUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/AYZHN4CJVSNDNHXPJ5S57UT5ELLONA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZWGA4TAOBQUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[CoderDeltaLAN]

Glad to hear pdflatex is working now, Chris. And yes, I agree that MiKTeX Console should expose the actual update error instead of failing without a useful explanation.

Also, to be precise, merely launching the installer “as Administrator” is not itself the same thing as mixing installation modes. The important distinction is the installation scope selected in the installer, followed by whether maintenance is performed in MiKTeX user mode or administrator mode.

Since your installation is under C:\Program Files, I would now treat it consistently as a shared/system-wide installation. Before reinstalling anything, open MiKTeX Console and explicitly choose Switch to MiKTeX administrator mode.

If Console still refuses to update, an elevated PowerShell should bypass the GUI and, more importantly, show the real error:

cd "C:\Program Files\MiKTeX\miktex\bin\x64"
.\miktex.exe --admin --verbose packages update-package-database
.\miktex.exe --admin --verbose packages update
.\miktex.exe --admin packages verify
.\miktex.exe --admin fndb refresh

If the package-database step reports a repository or download problem, list the available repositories:

.\miktex.exe --admin repositories list

Then retry using one repository consistently:

.\miktex.exe --admin --verbose packages update-package-database --repository "<repository URL>"
.\miktex.exe --admin --verbose packages update --repository "<same repository URL>"

If the command-line update succeeds while Console still fails, I would leave the now-working TeX installation alone for your deadline and regard this as a Console-specific problem rather than a broken TeX engine.

For something concrete the maintainers can diagnose, generate the installation report:

.\initexmf.exe --admin --report > "$env:USERPROFILE\Desktop\miktex-report.txt"

The relevant log directories are:

explorer.exe "$env:LOCALAPPDATA\MiKTeX\miktex\log"
explorer.exe "$env:PROGRAMDATA\MiKTeX\miktex\log"

MiKTeX does recommend a private installation for most individual users, but I would not replace a working installation in the middle of a hard deadline. I would first try the administrator-mode update above, preserve the exact output if it fails, and only consider reinstalling after the immediate work is safely finished.

[ChrisChiesa]

Hi again, Well, I've decided the deadline is a non-issue because I am unable to get acceptable results due to hardware limitations, so it's not clear when/if/whether I'll *ever even use *MiKTeX again -- or TeX itself, for that matter -- after this particular project. I'll probably keep it around "just in case" -- somewhere I have a TeX tutorial that I printed out in the early 2000s, that I could work through again -- but the high-priority impetus has abated. Now I know what people accustomed to using just the turnkey application that drove my company's product in 1988-1998 must have felt like, when something they wanted to do required escaping from the application and issuing commands at the system prompt. There is clearly an entire body of knowledge about MiKTeX, that you possess and I do not, that allows you to compose the specific command incantations to fix my problems... I have to take all of that "as stipulated," because I sure don't *actually understand *it -- and for me, after 60+ years of *always *understanding *everything *I've been doing, even when told by other people, this is a novel experience -- and an uncomfortable one, truth be told. But if it solves my problems (next time I bump up against them), *that's *the important thing! Thanks again, Chris

…

On Sat, Jul 11, 2026 at 10:50 PM Yosvel ***@***.***> wrote: Glad to hear pdflatex is working now, Chris. And yes, I agree that MiKTeX Console should expose the actual update error instead of failing without a useful explanation. Also, to be precise, merely launching the installer “as Administrator” is not itself the same thing as mixing installation modes. The important distinction is the installation scope selected in the installer, followed by whether maintenance is performed in MiKTeX user mode or administrator mode. Since your installation is under C:\Program Files, I would now treat it consistently as a shared/system-wide installation. Before reinstalling anything, open MiKTeX Console and explicitly choose *Switch to MiKTeX administrator mode*. If Console still refuses to update, an elevated PowerShell should bypass the GUI and, more importantly, show the real error: cd "C:\Program Files\MiKTeX\miktex\bin\x64" .\miktex.exe --admin --verbose packages update-package-database .\miktex.exe --admin --verbose packages update .\miktex.exe --admin packages verify .\miktex.exe --admin fndb refresh If the package-database step reports a repository or download problem, list the available repositories: .\miktex.exe --admin repositories list Then retry using one repository consistently: .\miktex.exe --admin --verbose packages update-package-database --repository "<repository URL>" .\miktex.exe --admin --verbose packages update --repository "<same repository URL>" If the command-line update succeeds while Console still fails, I would leave the now-working TeX installation alone for your deadline and regard this as a Console-specific problem rather than a broken TeX engine. For something concrete the maintainers can diagnose, generate the installation report: .\initexmf.exe --admin --report > "$env:USERPROFILE\Desktop\miktex-report.txt" The relevant log directories are: explorer.exe "$env:LOCALAPPDATA\MiKTeX\miktex\log"explorer.exe "$env:PROGRAMDATA\MiKTeX\miktex\log" MiKTeX does recommend a private installation for most individual users, but I would not replace a working installation in the middle of a hard deadline. I would first try the administrator-mode update above, preserve the exact output if it fails, and only consider reinstalling after the immediate work is safely finished. — Reply to this email directly, view it on GitHub <#1749?email_source=notifications&email_token=AYZHN4EZCPTHYXHHMVAYAVT5EL4GPA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZWGA4TKNRQUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-17609560>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AYZHN4CKBTK2JHLKLLYZEPL5EL4GPAVCNFSNUABHKJSXA33TNF2G64TZHM3DCOBZGIYTQOJ3IRUXGY3VONZWS33OHMYTANBRGI3TGMFBOYBA> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AYZHN4AIRVU6YFZD7SFMBDT5EL4GPA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZWGA4TKNRQUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/AYZHN4DFXDCC2AO5CIRU3ML5EL4GPA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZWGA4TKNRQUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>