Ending A Windows Installer Transaction Event Id 1042
Windows Installer – Like any software that performs installations, if Windows Installer has a problem, so does the CCA. Event ID At the start / end of the above sections of logs, I was able to determine all the relevant loglines were written between these two log entries. Mar 11, 2009 - The description for Event ID ( 1035 ) in Source ( MsiInstaller ) cannot be found. Event ID: 1042. Ending a Windows Installer transaction. Event Type: Information Event Source: MsiInstaller Event Category: None Event ID: 1042 Date: Time: 12:29:07 User: NT AUTHORITY SYSTEM Computer: WS-IT Description: Ending a Windows Installer transaction: fileserver2 SoftwareDistributionService TextPad 5.msi.
I have a brand-new machine that we just installed Windows Server 2008 Enterprise on about two months ago. In the event log, I am seeing thousands of EventID 1035 logged. This is MsiInstaller reconfiguring about a dozen products over and over, looping about every half-hour. Has anyone seen this? As a beginning, I did a general web search, and most solutions revolved around Dell System Center or Google toolbar being installed as the culprit.
We have neither of those products installed. Thanks for your help, Dale. UPDATE:. Windows Installer features ' self repair' for installed applications. In essence this means that it will keep checking whether the files on disk and settings in the registry match what the respective package originally installed. These checks are generally not performed for everything that the package installed, but for what is referred to as ' key paths'. In situations where you see self repair running in cycles, it generally means that some process on the system or another MSI has changed settings on the system that the package that subsequently self-repairs also changed.
Like the guy said, it's like a humidifier and a dehumidifier fighting it out in the same room - or a dog chasing its own tail. You don't get anywhere till the conflict is found and eliminated.
The MSI file will keep going 'this is my resource, I am changing it back' over and over. What is needed is to identify the conflict that the MSI files or system processes are quarreling about:.
There are also other design errors in MSI files that can trigger the same problem such as key paths set to hard coded, user-specific paths: C: Documents and settings user1 Desktop. This path will not be found for another user logging on, and self repair results.
Another example is key paths set to folders that are not writeable for the System account. Still another example is a key path set to a temporary file (which the system will delete eventually). As you see, there are many scenarios but always the same problem: an MSI file is checking that the current installation is correct, and finds a discrepancy that it then tries to fix. I can confirm the problem is triggered by WMI queries to the Win32Product class. But as documented in this other question below, you cannot use the Win32regAddRemovePrograms if you don't have SCCM/SMS installed and even if you do would have to use Win32regAddRemovePrograms64 to get a list of 64bit programs None of this was documented before as a bad thing, actually as the proper way to do it.
I think the choice by Microsoft to do a repair check at the same time as responding to the query is just bad design. A query should never cause changes to a system, that should be a different 'function' (WMI method).
A sensible design could have included a periodic check into their 'system maintenance' featrure of the newer operating systems, because that's also configurable and makes sense to users/administrators. Anyway this was an old server, actually about to be decommissioned (Windows 2003 64bit). But it did happen on all of our servers for many years (that was a major hit to performance now it's confirmed).
Beginning A Windows Installer Transaction
So I'll have to check again on the newer 2008 R2 servers to see if this will be an ongoing production issue or not. But what I really wonder is how the heck I can explain to teams of packagers and support engineers that they must not use that WMI query/API. We've got hundred of scripts and tools written by lots of different people for 1000s of packages. There's no way it'll ever happen.
So this behaviour should be fixed as a critical design fault by MS if it's still occurring in 2008 R2 and other supported OS versions. We'll certainly escalate it if it's still the case!
So I’m installing some software by hand remotely. The software decides to throw a fit and spit out this error Error code 1317 unable to access C: Users All Users Application Data. Hmm Well this isn’t quite right I take a look and the All users folder was not listed on c: users when logged onto the machine despite having show hidden folders enabled. I jump out of my remote session c$ onto the PC from my actual PC – All Users folder was listed Okay, so I check the perms on the folder. Yep, everything as it should be After a few minutes of pondering I was struggling to why this all seemed so familiar. All Users Application data seemed familiar Distant but familiar Especially when it comes down to half hacked together exam software from back in the XP days that should really have been tested before they made it to public release. That’s when I seemingly opened Pandora’s box of repressed memories stemming from my first ever year in IT when I was a lowly apprentice.
The faint sounds of DickBoss laughing maniacally by the coffee peculator while the office celing collapsed around us, all while the scent of the recently purchased bacon, egg and mushroom sandwich from the greasiest of grease filled cafs emerged, briefly overpowered the nasal barrage that was the scent of decomposing rats on a warm summers day that wafted from the floorboards beneath us. Snapping back from my PTSD incident, that’s when I remembered that Windows Vista, profiles were the changed and the whole ‘Documents and Settings lark was yanked out and replaced with C: ProgramData and C: users. The remains of the old C: documents and settings All users (Now C: users All Users) folder acts as a symbolic link – the folder is effectively a shortcut to another location, but can still be mapped to and pointed to like a traditional folder.Side note, I found out that the Documents and settings folder still does exist in Windows 7, but is locked down. Open explorer and go to C: Documents and Settings All Users and you’ll be redirected to C: Program Data Anyway, I C$’ed into borked PC,the looking at the properties of C: Users All Users Symbolic Link and found it was pointing at a non-existant directory:D: All Users I deleted the duffed folder and continued. I Remoted back onto the PC in question and attempted to Re-established symbolic link. I was able to do this by running command prompt as admin and running the following command – c: windows system32 mklink /J.Target path.Destination path.
– in this case mklink /J c: ProgramData “c: users All Users”.success. Attempted to reinstall software and the bastard Issue persisted. I tried a couple of times to install it again but each time it spat out, what looked to be the same, error message. However after the third time I noticed that the path was actually slightly different.
The error it spat out was trying to write to c: users all users application data – with the new symbolic link established the Installer then saw c: Users All Users as c: ProgramData Application Data I tried to access the c: ProgramData Application Data folder and got a Access Denied message. I went into c: ProgramData and checked the folder properties of Application Data. Sure enough I found that it itself was a symbolic link – which again was pointing at a non-existent location on D:. After confirming where c: ProgramData Application Data should be pointing to (in this case, back on itself) on my own PC, I repeated my earlier steps. Ran CMD as admin and ran the following command – mklink /J c: programdata “c: programdata Application Data” Attempted to install the software and was successful. Ah Microsoft Office.
A program embedded into my very soul. You see, I’m a tech of a modern generation, rather than actually learning about computers in our IT lessons – WE USED OFFICE TO DO THINGS LIKE WRITE LETTERS AND MAKE SPREADSHEETS! Bollocks to that. It was pretty much when I was in Middle School (ages 9-13) that I became aware that I was destined for trouble.
I knew I was in for a lifetime of pain and misery when I started providing IT support to some of my teachers. Alas, not one to argue the toss with the powers of fate, I admitted defeat and gave up on my dreams of being a rock star, and ended up in IT.
Alas, while I cry. Lets get to the meat and potatoes of this issue. You get this issue when you try to install office. Check the event logs. You get a bunch of non-descript information events as follows – – Event ID 1042, Source MSIEXEC Ending a Windows installer transaction. C: MSOCache Allusers Office64MUI.msi. Client Process ID – Event ID 11708, Source MSIEXEC Product: Microsoft Office Shared 64-bit MUI (English)2013 – Installation operation failed.
Error code 1603. What do you try? Well theres a few things online that can be found with a moderate amount of googling. The first being that the SYSTEM account doesn’t have permission to access the folder in which you are trying to install office.
Check out the fix for that here – Another thing that I read was that this issue was due to the Task Scheduler service was failing horribly. Again, this was not the case for me. So Google appears to be failing. Well, firstly, I needed more information as what I had was clearly not returning anything useful.
To get more information, I enabled verbose logging on the Surface Tablet I was working on. To do this, add the Debug and Logging reg keys, as shown in the image below to – HKEYLOCALMACHINE Software Policies Microsoft Windows Installer Next, I needed to create a log. So I ran the office exe again for it to fail. Nothing unexpected yet.
While this is going on a log file is being created in the%Temp% directory (Or C: users%username% App Data Local Temp for those who like the long way round) After looking through the other log files I found that the second most recent log was the one I was after. Side note – If you are experiencing this issue, the easiest way to spot the file is that it will have an MSI name and will be (usually) just slightly larger than the SetupExel. There a lot of superfluous information here in the log. We just want to look for anything and everything about ERRORS. Easiest way to navigate this is just to do a Ctrl+F and search for the word “Error” within the document. This is exactly where Office is having a massive fit.
Next step is to look at the logs prior to this in search of what is causing the issue. You can clearly see in the log directly above this that the fault is occurring when it is trying to create a scheduled task called OfficeTelemetryAgentLogOn from a.xml file. My fix for this? Find a PC that has Office successfully installed and navigate to c: Windows System32 Tasks Office. In there there will be three files named:. Office15 Subscription Heartbeat. OfficeTelemetryAgentFallBack. OfficeTelemetryAgentLogOn Well I’ll be dammed.
One of those is the task we’re looking for. Copy and paste that bastard from your working PC straight to the same directory on your borked PC and attempt the install again. With any luck it should work. Since there seems to be nothing sensible online about this error. I thought I’d write up a little piece about a recent issue I experienced to help save another tech wading their way through the pile of proverbial that a Google search will return. If you get hit with by a Service Error 79, here’s a couple of things to try.
Perform a cold reset 1. Turn the product off. 2. Perform one of the following steps: – LCD control panel models: Simultaneously press and hold the right arrow button and the Cancel button. Keep these buttons depressed as you turn the product on. – Touchscreen control panel models: Press and hold the lower right quadrant of the touchscreen.
Keep the quadrant depressed as you turn the product on. 3. When the Permanent Storage Init. message appears on the display, release the buttons. 4. When the product has finished the NVRAM initialization, it returns to the Ready state. Update the firmware If this doesn’t work (which it didn’t for me), then simply update the printer’s firmware. Here’s a link to the page here – If it was my own device, however, I would have loved nothing more than to have thrown the damn thing out of the window just to watch it explode into thousands of little pieces.
Give me a any day. Written by Posted in, Tagged with, February 28, 2016.
The bane of my very existence, alongside poor coffee and pterodactyls. Basically this all started off when a user contacted me saying that they could no longer convert office documents to PDFs using Adobe Contribute a very non-descriptive error mesage appeared stating “Unable to convert to PDF” Fair play, another day and another ticket. Initially I thought it was some sort of acrobat issue as acrobat X pro was previously installed on the PC and there are MANY documented issues between Office 2013 and Acrobat X. Random tidbit here, Adobe Contribute actually installs a copy of Acrobat Elements so the “InsertOfficeDocAsPDF” script located in Contribute’s config files can call upon Acrobats magical ability to create PDFs.
Turns out Acrobat wasn’t the cause of the issue. I next noticed that there were several versions of contribute (v4 and v5) installed – this may mean that the plugins in office are indeed unable to run with Office 2k13, because compatibility and what not. After uninstalling these burdens of life, they somehow arose from the grave, reinstalling themselves upon startup. Okay, Group policy. So I checked the GPOS of my network and ‘lo and behold they were not set to apply to this specific PC. Turns out there was a key in the registry that contained a link to a Group Policy object which called a script to install the software.
With a swift smash of the delete key, these issues were gone. After trying to add a word document as a PDF, only for it to fail again, I ragequit straight into my lunch-break. After a delicious and a cigarette, I bit the bullet and contacted Adobe. After several different calls I eventually got what I wanted to hear from them – That there are known compatibility issues with Adobe Contribute 6.5 and Office 2013. These compatibility issues aren’t documented anywhere on their site, apart from the following line in their System Requirements for Contribute 6.5 “Microsoft Office 2003 or 2007 required for the Microsoft Office plug-in” Now you know what they say, assumptions make an ass out of you and I and it certainly has here. I naturally assumed that because it worked with such old versions of office such as ’03 and ’07, then surely it would work with ’13.
Adobe Contribute is buggy as hell with Office 2013 (and possibly 2010). I don’t know if there will ever be a resolution to this, but for all techs like me who have (and are) scouring the net for some validation or answer to their contribute and office issues, let this bring you peace of mind that you’re not alone.UPDATE. Below is a chat I had with an Adobe bod.
Ending A Windows Installer Transaction Event Id 1042
Turns out this is a compatibility issue. Well I’ll be dammed. Yes, basically what happens is that ever since upgrading to office 2013, whenever I use contribute to upload an office document to a contribute page I get the following error message “unable to convert to PDF” in a dialogue box 4:19:37 PM me: When I was using office 2010 it worked fine 4:19:48 PM Maharana: You are using Office 2013. There could be compatibility issues here as it was never designed to work with Office 2013 4:22:15 PM me: I just find it strange that this would be the case, as when I am uploading the files, I use the explorer dialogue box via connect itself and do not use the plugins – I don’t open office plugins throughout the process.
4:22:41 PM me: Could this still be part of the compatibility issues you mentioned? 4:23:23 PM Maharana: Yes when ever contribute interacts with office the plugins are used.
So this is a compatibility issue 4:24:23 PM Written by Posted in, Tagged with, August 6, 2015.