software crashes on a third party computer

Question

I have a problem on a customers computer, my software is crashing on it!! It has XP, SP3 installed. I have an XP with SP3 installed and the software works fine on it.  Obviously it sends data to microsoft when it crashes, is there anyway of me having access to that data AND making sense of it? Any help gratefully appreciated

Answer 1

Let me tell you when a Crash Occures!

  Every program bug has the potential to cause a crash.

- Accessing uninitalized memory / wrong addresses. Null pointers, array bugs, pointer bugs etc.
- Jumping to wrong addresses / using invalid function pointers.
- Out of memory. Stack / global RAM / heap / program memory / HD memory...
- I/O errors. File handling, pipes/IPC, hardware I/O, registry I/O etc etc.
- Accessing corrupt hardware.
- Divide by zero.
- Deadlock bugs. Waiting for resources that are never released. Could be both hardware and software resources.
- Semaphore/mutex bugs. Multi-threaded programs that don't protect shared variables.
- Crashing the OS through wrong use of API functions.
- Doing dumb things in assembler, such as not stacking CPU registers before using them.
- And on and on and on...

---

Thanks Mike --------Please mark as answer if it is useful----------

Answer 2

thanks Gents, I will be using process monitor to help find where inside the the program it is crashing. I guess I was hoping you might tell me how I could get the software to generate a report that can be analysed in a debugger.

The other thing. I have not received any alerts to say they has been responses to this problem.

Answer 3

Answer is 'Dump'. Create user dump,when a first chnace, second chance exception occurs. there are lot of tools avilable for that .Try Microsoft's debugDlg

Download   http://www.microsoft.com/downloads/details.aspx?FamilyID=28BD5941-C458-46F1-B24D-F60151D875A3&displaylang=en

How to use http://www.faultwire.com/solutions/using_debug_diagnostic.php

---

Thanks Mike --------Please mark as answer if it is useful----------

Answer 4

Mike_999 is right about getting the crash dump.  You may also want to have your customer use the tool ProcDump from sysinternals to generate the crash dump.  Make sure that you are generating PDB files with your builds and that you save them because the crash dumps won't do you much good without them.  If you do have them, the crash dump will be able to show you exactly what caused the crash.

Answer 5

I managed to get process monitor on the computer. The first error message (or no success ) is:

11:13:31,1559991 mysoftware.exe 5908 RegOpenKey HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllVerifyCertificateChainPolicy NAME NOT FOUND Desired Access: Read

I do not know what this means?

Answer 6

Either Assembly don't have minimum permission to access windows registry. You should modify your code with the help of namespace System.Security.Permissions or Registry key doesn't exisit.

have a look at this Post from MSDN http://msdn.microsoft.com/en-us/library/ms229913.aspx

---

Thanks Mike --------Please mark as answer if it is useful----------

Answer 7

Thanks Mike, does that mean that mysoftware does not have all the permissions or the registry is corrupt?

I think the problem is the software does not have permission to write to files which is causing the program to crash.

Answer 8

Most cases, workstation user will have minimum permissions. Which means, they cannot read/write registry data. This was one of the major consideration of  introduction of Config files. you can use config file for saving settings and encrypt the file when storing into disk.  its a good practice , that to test our application with a minimum permissions.   But if you really need to access registry, then only way is using Security.Permissions  , and put attributes on the methods/class which is about to use registry or any such restricted resources. This will be additional work, but your application's stability will be improved.

---

Thanks Mike --------Please mark as answer if it is useful----------

Answer 9

Thanks Mike, I know it looks like mysoftware.exe is trying to access the registry, it was not programmed by me to do so. Is there another reason why this is happening?

Answer 10

There could be possiblity your computer is infected by some virus/malware. It sounds like DDoS(distributed denial-of-service attack ) for me.It is an attempt to make a computer resource unavailable to its intended users. have a lookt at this Wiki page for more details http://en.wikipedia.org/wiki/Denial-of-service_attack

---

Thanks Mike --------Please mark as answer if it is useful----------

Answer 11

Is this not part of a normal operation?

Answer 12

Most cases, registry permissions are restricted for domain user other than Administrators. It depends on computer policy(which is found under MMC(type MMC in Run) ). This is enabled for Administrators only.

You have 2 options
1. Get registry permission enabled for the users.
2. Modify the code for requesting registry permission at run time.

if you have tried both of above, still not able to make it work, possibly machine is malfunctioning, due to various reasons, virus is one of them.

---

Thanks Mike --------Please mark as answer if it is useful----------

Answer 13

rockmate,

Most likely the registry is not corrupt and there is no malware on the system.  It's possible there is malware, but unlikely that this is the cause of your crash.  If the registry was corrupt, every program they had would be crashing.

You are going to spend so much time trying to debug this looking at procmon logs.  There is so much registry access going on that you have no control of and have no idea is even running.  Whenever you call a simple Win32 API it can call the registry many times for reasons you don't even know about.  APIs check the registry all the time to see if policies allow a certain function to run and they perform many other checks as well.  A lot of these registry keys don't exist and that is expected, but you will see NAME NOT FOUND in the procmon log.

You need to have your customer get a crash dump or you will most likely be trying to figure this out indefinitely.

Eric

Answer 14

eric,
this is look like more than a programming issue. I did few R&D on this, as per given registry key, the application was trying to invoke certicate Services. this is an active directory service, which might be not configured properly.

rockmate,
 you may need to ask questions about Certificate Services in TechNet forums.  I guess this application suppose to run in Windows Server machine. Not sure...

---

Thanks Mike --------Please mark as answer if it is useful----------

Answer 15

Hi Mike_999,

I don't think this has anything to do with the crash.  It is just the first unsuccessful registry call that rockmate found in the log.  If you run procmon, you will find tons of these entries. 

rockmate
If you want to use procmon logs, you should at least get a crash dump and get the process id and thread id of the crash, then filter that in the log and find out what the last activity is. 

Come to think of it, you can filter on the process id, which you probably have done already.  Then filter on each thread id.  The offending thread will probably have some Dr Watson activity at the very end of it, like possibly creating mini dumps in the temp folder, accessing WER (Windows Error Reporting)registry keys, and also launching an app like drwatsn.exe.  When you find this thread, look to see what is happening immediately before this other activity takes place.

If you have the crash dump, it will tell you what the cause of the failure is anyway.  This will be the most valuable troubleshooting skill you will ever learn.

Answer 16

Hi Mike_999,

I don't think this has anything to do with the crash.  It is just the first unsuccessful registry call that rockmate found in the log.  If you run procmon, you will find tons of these entries. 

rockmate
If you want to use procmon logs, you should at least get a crash dump and get the process id and thread id of the crash, then filter that in the log and find out what the last activity is. 

Come to think of it, you can filter on the process id, which you probably have done already.  Then filter on each thread id.  The offending thread will probably have some Dr Watson activity at the very end of it, like possibly creating mini dumps in the temp folder, accessing WER (Windows Error Reporting)registry keys, and also launching an app like drwatsn.exe.  When you find this thread, look to see what is happening immediately before this other activity takes place.

If you have the crash dump, it will tell you what the cause of the failure is anyway.  This will be the most valuable troubleshooting skill you will ever learn.

thatz perfect eric.

rockmate, get your dump, start analysing it, no point for further discussion, it won't lead you to actual issue.

---

Thanks Mike --------Please mark as answer if it is useful----------

Answer 17

Thanks for your help. I fixed it. Process monitor showed me where agouts in the program the problem was from that I located it. The registry was a diversion. I never used dump, but would like to know more about using that in the future.

Answer 18

Thanks for your help. I fixed it. Process monitor showed me where agouts in the program the problem was from that I located it. The registry was a diversion. I never used dump, but would like to know more about using that in the future.

can you  be bit more clear, what was the issue?, it will help us to study further.

---

Thanks Mike --------Please mark as answer if it is useful----------

Answer 19

A charecter array is created for a path, path[80]. The array was not big enough to store the path. So the program crashed when a charecter was added to path[85] or it crashed when it attempted to open the file. Either way, when I defined path as path[MAX_PATH] it fixed the problem.

Answer 20

The tricky bit was finding the bug on the other computer. The username was just a charecter or two too long, that was why I did not get the problem on my computer. Process Monitor was a magic, I did not appreciate what it was churning out at first, so when I came accross the first error I assumed that was the main cause. I did suspect there was a permissions problem ie not being allowed to write to files. Once Eric mentioned that there could be lots of problems reading the registry I realised it could be a red herring and looked further down to just before it started to crash. That told me which was the last file that was successfully created so I zoomed into that part of the program.

Answer 21

Congratulations and nice investigative work! ;)  Thanks for sharing the details.