Jump to content


  • Content Count

  • Joined

  • Last visited

About dgurrol

  • Rank
    ISF Newbie

Profile Information

  • Location
  1. True, true, just thought, the extra measure for being unattended would help someone else in events of power issues, far end computer crashes, etc. I 100% agree with you and I am fairly certain this is due to the SATA controller (it's somewhat specialized so driver updates are rare). Thank you for the extra look though. Take care.
  2. Unfortunately the procmon did not log during the initial failure (it might be a big file too though as the job I run typically lasts for about 35-60 minutes). I am not sure if you want to see anything else specifically so I am using default filtering and nothing extra. PML files will include all events not just the displayed events. Before clicking retry I opened the file - I had to do some obfuscation. I then hit retry 4 times with no luck. I built the screenshot up for you and obfuscated what I must. I then opened procmon and closed everything that was not needed, allowed all closed TCP connections to complete their move from TIME_WAIT to gone (netstat -an right after closing everything and then 2 minutes later to accommodate the TCP/IP default timeout). I captured clicking the retry button 7 more times and then I stoped procmon from capturing more events I will email the password to the 7zip file and I hope using 7zip is not an issue for you (I personally hate installing things because someone else uses them, but I needed to get the PML file under the posting limit) I should have thought about just putting the image in the pw protected 7zip file so I would not have had to take the time to sanitize it, I just can't show the data publicly. Logfile.7z
  3. Here is a screenshot of the exact error.
  4. I will include procmon setup and log capturing in my automation, should not prove too difficult. May take a few runs to encounter the issue though, so I will be back when I have something to share.
  5. There, the donation is finally complete, but I had to sign up for a PayPal account....oh well nothing like another password and account to keep track of to keep the mind alive! Take Care LIGHTNING UK! Cheers and all the best to you.
  6. dgurrol

    Please, No Open Candy - I'm willing to pay!

    James, My friend, nothing in life is ever truly free :-) I understand your request fully and while I have ZERO affiliation with ImgBurn, other than that of my daily use of the application, I have to say that with a little research and maybe a better antivirus application your concerns may be promptly addressed. OpenCandy is not MalWare - it should be properly classified by any good AV program as AdWare OpenCandy runs during installation of ImgBurn and once the installation is complete and you exit the installer's window(s) OpenCandy cleans itself up. OpenCandy is truly doing no more than any installer displaying graphics, notes, and self advertising, the only difference is that the OpenCandy enabled installer profile's your computer and displays advertising that may be more targeted to you specifically based on the profile. http://www.opencandy.com/faqs - a quick read should give you a better sense of things http://oclink.us/occleanup - nabs a nifty little cleanup tool from a dropbox account I have Avast Endpoint Protection (a business version) running on my PC, I also have Kaspersky Endpoint Security Business SELECT 10 running on my other PC and neither of these top rated AV products flag the ImgBurn installer with any warning or issues whatsoever. I scan all installers with my AV before install and contribute to cloud analytics with any AV application that contains the option. My AV settings also san ALL files on open/execute. The optional software you are asked to install after the start menu selection is more than likely OpenCandy's work. Select custom and uncheck the install option. Easy as that. I don't think enough of us would pay, I also think there would be more people stealing the software through credit carded copies, cracked versions, keygened, take your pick, I am pretty sure I am right too. The developer deserves something for the work (or their work). The fact that this extremely well written program is and remains free just floors me. I for one could not afford to buy the three copies I would need and use daily. I only posted to this thread because I simply just can't stand missinformation and OpenCandy is not MalWare period. I have seen nothing in ImgBurn to warant such a classification. I read what appear to be the developer's posts on this forum, answering some of the most ridiculously formed questions ripe with gramatical and spelling errors, as well as jumbled thought processes and I am left impressed and appreciative of both the developer and the application. I am not a srill for the application or developer, I am a Senior Systems and Network Engineer with 30 years deep and wide IT experience. I have seen a LOT of crapware, malware, and adware, this application, even with, what many tag as dubious, OpenCanday included to offer me optional software to install. Pay attention to your installations, read what is in front of you, and no one gets hurt :-)
  7. When running ImgBurn from the command line there is no automated way of handling read errors. This is a specific example, but the logic may be able to be applied to any read issues in build mode. Files are being added to the ISO file in build mode and for whatever reason a file is no longer available or encountered a read error... "Cannot read from file: <path to file>\<file> Reason: the specified network name is no longer available." Retry Cancel ...when I notice the error, sometimes hours later, I can browse to that file just fine and even open it, but when I click the retry button the same error message appears over and over. This leaves me but one option, cancel and delete the incomplete ISO file...and start the process all over again. It would be nice to: automate a retry __ times and continue if possible. automate a retry __ times, cancel if still in an error condition, and delete incomplete ISO. automate a retry __ times, cancel if still in an error condition, and keep incomplete ISO. automate a retry __ times, cancel if still in an error condition, delete incomplete ISO, and attempt the build again Option #4 may need some thought, could end up in an endless loop attempting to build an ISO and running into the same error over an over again, maybe a build attempt retry or something??? Since this was not a "crash" there is not a bugcheck file and the logging data would not really help, it merely shows the time of the error message. Thank you for your time and consideration. I really appreciate this product's usefulness. P.s. by the way and so you know... Been trying to donate US $50 to ImgBurn via PayPal without a PayPal account. Even though I have selected United States, the County/Town selection does not change to something a little more U.S specific :-) it remains linked to the Queen's lands and though I have some friends and family in Suffolk England, that with my other U.S. data is just not going through :-) Just thought you should know. Why? $50 - from what I can tell this is a better programmed application than WinISO, MagicISO, and PowerISO (which are all good on their own merrit by the way, PowerISO being closest with command line options as well). I appreciate a good mind and some of the logic I can clearly see from the way the application runs, handles options - so many by the way, and deals with it's own errors independant of many (maybe not all - can't tell, have not taken the time to tell) common MS .dll's means something to me. So, with those guys charging $29.99 and the fact that I bought ALL of them and use them rarely compared to ImgBurn is free and I use it DAILY, you deserve at least the $50! As soon as I can get this PayPal business worked out, the donation will be real :-)
  8. The funny thing about XP and mapped drives is that they are per session not per system and this is likely true with Windows in general. Here I am logged in as the local adminstrator on a domain connected machine. I open my computer and via the address bar type \\server press enter and then authenticate with domain\user and password. I am now able to see this "mapping" via the net use command. Microsoft Windows XP [Version 5.1.2600] © Copyright 1985-2001 Microsoft Corp. C:\Documents and Settings\Administrator>net use New connections will not be remembered. Status Local Remote Network ------------------------------------------------------------------------------- OK \\server\IPC$ Microsoft Windows Network The command completed successfully. C:\Documents and Settings\Administrator> Now I run the command prompt as SYSTEM via psexec -i -s -d cmd and in the command prompt running as SYSTEM type net use and press enter. Microsoft Windows XP [Version 5.1.2600] © Copyright 1985-2001 Microsoft Corp. C:\WINDOWS\system32>net use New connections will not be remembered. There are no entries in the list. C:\Documents and Settings\Administrator> Launching ImgBurn as SYSTEM via psexec -i -s -d "%programfiles%\imgburn\imgburn.exe" results in that crash I sent in bugreport2.txt previously. Now I go back to the local administrator's command prompt window and do a net use * /delete /yes to remove that \\server\IPC$ "mapping". At this point explorer is running under the local administrator's permissions and shows C: (XP boot drive), I: (second physical drive) and D: (the physical optical drive). Flip back to the SYSTEM command prompt and redo the imgburn as system command...and...same application error window appears. Just a reminder here, the psexec thing is being done so someone else can follow along and emulate what it would be like for the Task Scheduler job that was created via the AT command. When you mentioned the mapped drives thing it triggered my brain to think "...well hey the job may be running in the SYSTEM context, but that /interactive switch may come into play with what that 'ol lighning bug said..." no offense intended, it's just how this crazy head of mine works ;-) So I fired up the SysInternals diskmon tool under the local administrator context and then fired up ImgBurn as SYSTEM - all reads and writes shown were against disk 0 (that would be C:). I then fired up diskmon as SYSTEM and tried ImgBurn as SYSTEM again...same results. Hmmm...lets try procmon. I can see ImgBurn enumerating through devices listed in the registry, including my disabled and not running Virtual Clone Drive (VCDDaemon.exe not running, removed from starting up with system and number of drives set to disabled - I turn this on and off as needed only). Tried again after uninstalling Virtual Clone Drive...same. Uninstalled anything that may emulate or play with drive mappings - RealVNC 5.1.0...Avast 8 Endpoint Protection...same. I then used task manager to close everything running under the local admin's context (except for the command prompt) - sometimes explorer gets fussy when another tries to open (only one explorer.exe at a time regardless of what user context it is running under). I was not sure how/what your drive tree creation used for the form so I just played it safe and killed explorer. I then stopped EVERY service that I could. I also disabled the network interface as well. Same... attached is the bugreport.txt file and the procmon data (7zip compressed to meet your upload requirements) captured from start (just after all administrator processes were killed and every service possible stopped) to finish, closing the application error window by clicking the close application button. If you have procmon I did not use any fancy filters - it's all there using the default settings. I really hope this helps you. For what it is worth, it really looks like something is not visible or accesible or enumerated for the SYSTEM account, but I just cannot tell what. It may be somewhere in the device tree of the device manager which get enumerated by ImgBurn via the registry (i.e. an old USB drive not properly disconnected or configured, or even some sort of Dell virtual hardware). Logfile.7z bugreport.zip
  9. When scheduling a job from the command line via the AT command, the scheduled job runs in the SYSTEM context. When the job fires you are presented with ImgBurn's application error handling window - nice work by the way! The command I am using to schedule the job is: at 04:00 /interactive /every:M,T,W,Th,F,S,Su "C:\ADMIN\RECORDINGS.cmd" See bugreport1.txt The /interactive allows me to logon as any administrative user and see what is actually happening by having any UI called from the script to be displayed. ImgBurn.exe version I am using is This can QUICKLY be reproduced by using SysInternals psexec command: PSEXEC -i -s -d "%programfiles%\imgburn\imgburn.exe" See bugreport2.txt This is reproducible on several Windows XP SP3 machines I have tested on. I am to begin testing my script on Windows Vista SP2, 7, 8, 8.1, Server 2003, 2008, 2008 R2, 2012, and 2012 R2 where I belive the scheduler's options on all but server 2003 will handle this quite nicely, but the XP system with it's low overhead is my true target. I know XP is out the door - truly not an issue as long as ImgBurn will run on it. Once complete the VM will be configured in a non-persistent mode. I also know there are other script methods and tools I can use, I am familiar and adept with most of them. The requirements demand the smallest resource utilization footprint as possible, nothing additional installed beyond critical and recommended updates for XP as well as anything required for ImgBurn to function properly. My only hiccup is this error. I do have a workaround that is acceptable, but not preferred - run the job as a local user. There are a few drawbacks to this though, none of which are pertinent to this bug report, but I would be happy to share if needed/desired. bugreport1.txt bugreport2.txt

Important Information

By using this site, you agree to our Terms of Use.